Subject: [alpine-devel] 3.3 proposal: reduce number of SUID binaries as much as possible

From: William Pitcock <[email-masked]>
Date: Tue, 26 May 2015 04:32:01 -0500

Hello,

I would like to see a general reduction of SUID binaries where
possible.  For example, a lot of APKBUILDs have options=suid when
there's probably no real reason for it.

Examples include ...

    main/apache2
    main/atop
    main/email2trac
    main/fping
    main/fuse
    main/haserl
    main/krb5
    main/mailx
    main/man (i have no idea why you need SUID to view manpages???)
    main/mate-applets (why would we ever give a GUI defacto root???)
    main/nagios-plugins
    main/vte
    main/xscreensaver

We should really investigate why these packages need suid and then fix
the problems.  I guess they want read or write access to some
filesystem path that is normally hidden.  In this case, we should fix
the filesystem so that we're not hiding junk we don't need to.
Security by obscurity isn't.

William

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Orion <[email-masked]>
Date: Wed, 27 May 2015 13:19:01 -0700

On Tue, 26 May 2015 04:32:01 -0500

> there's probably no real reason for it.

I fully support this endeavor! :D I will gladly help out and maintain
this project. However, I would prefer that we start with the base system
before we move onto other packages. So I think a great first attempt
would be removing as many SUIDs/SGIDs from a bare bones alpine-mini
install.

-- 
keybase.io/systmkor

---

From: William Pitcock <[email-masked]>
Date: Fri, 29 May 2015 11:43:39 -0500

Hi,

> would be removing as many SUIDs/SGIDs from a bare bones alpine-mini

As far as I know there's no SUID/SGID enabled packages in alpine-mini
other than bbsuid which we install to proxy only the SUID-needing bits
of busybox.

William

---

---

From: Timo Teras <[email-masked]>
Date: Tue, 26 May 2015 13:04:38 +0300

> Security by obscurity isn't.

Patches are welcome :)

And now that apk handles xattr's it'd be trivial to use filecap in some
of the cases. E.g. fping should really need only NET_RAW and
possibly NET_BIND_SERVICE. Or perhaps it would even work using the
non-privileged ICMP sockets.

Do note that this also applies running system daemons as non-root. So
the list of packages is a lot larger. E.g. I just recently converted
strongSwan to run as 'ipsec'.

But yes, this is something we want to work towards. And I hope we get
many patches on this :)

/Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 26 May 2015 13:55:37 +0200

> there's probably no real reason for it.

yes. i'd love to clean up this.

>     main/man (i have no idea why you need SUID to view manpages???)

!!!?

lets purge it. mdoc-ml is there. i think there is also a mandb or
something from GNU.

>     main/mate-applets (why would we ever give a GUI defacto root???)

I suspect many of them needs major refactoring for fixing it properly.
For example, kernel now has support for icmp echo without root, but i
have not been able to make it work. you need refactor the ping applications.

IIRC fping tries open the socket with SOCK_DGRAM and fall back to
SOCK_RAW (which requires root). I think this works on OSX, but to make
it work on linux you need refactor lots of other stuff too.

> Security by obscurity isn't.

Yes. we should try fix as many as possible.

---

---

From: Isaac Dunham <[email-masked]>
Date: Tue, 26 May 2015 06:46:44 -0700

> there's probably no real reason for it.

Perhaps a workaround for grsec limits on sysfs/procfs permissions?

>     main/man (i have no idea why you need SUID to view manpages???)

On Debian, this is an install-time choice: suid allows caching manpages
in "catdoc" (preformatted text) format.

>     main/mate-applets (why would we ever give a GUI defacto root???)

Yikes.
I'd guess this might be the same as atop.

>     main/vte

Something to do with ptys, I'm not sure exactly what.

>     main/xscreensaver

A screensaver needs to be able to lock the screen, and presumably
also require a password.

---

---

From: eleksir <[email-masked]>
Date: Tue, 26 May 2015 23:19:05 +0300

Sure. Let's remove suid from sudo and su. It will be clever joke when 
you try to switch to root and fail. Go ahead you security freak, remove 
all suid bits and patch kernel/libc to remove all roots of this suid evil.

C'mon people, stop already this talks about "cleaning" system. Submit 
patches, make upstream (not distro maintainers) accept them.

---

---

From: Bartłomiej Piotrowski <[email-masked]>
Date: Wed, 27 May 2015 23:22:45 +0200

On Tue, 26 May 2015 23:19:05 +0300
> patches, make upstream (not distro maintainers) accept them.

+1. Let's focus on upstreaming our work.

BP

---

From: Orion <[email-masked]>
Date: Wed, 27 May 2015 18:15:17 -0700

On Tue, 26 May 2015 23:19:05 +0300
eleksir <[email-masked]> wrote:

> you try to switch to root and fail.

Well with certain roles within a grsec policy that may make sense. :P
For example if you wanted to do some malware sandbox testing.
 
> Go ahead you security freak, remove all suid bits and patch
> kernel/libc to remove all roots of this suid evil.

https://imgur.com/Hej4ZKh

> patches, make upstream (not distro maintainers) accept them.

As an end-goal I agree. I think we should try to push these patches back
up-stream to reduce the work distro maintainers need to do. That said
many of these developers don't care about security or they just don't
want to have to change. 

To help push various packages following the 'principle of least
privilege' we should

1. Build working examples on Alpine
2. Automate or simplify this process
3. Communicate with and push to upstream developers

-- 
keybase.io/systmkor

---

From: Natanael Copa <[email-masked]>
Date: Thu, 28 May 2015 08:03:13 +0200

> all suid bits and patch kernel/libc to remove all roots of this suid evil.

He said "where possible" and  "when there's ... no real reason for it".

> patches, make upstream (not distro maintainers) accept them.

We want fix it upstream yes. I still think its a good idea to look over
the places and submit bugs upstream.

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 28 May 2015 08:09:29 +0200

On Tue, 26 May 2015 06:46:44 -0700

> Perhaps a workaround for grsec limits on sysfs/procfs permissions?

There should be a boot option for disabling sysfs protection and there
is a group 'readproc' where you can put users who should have read
permissions to /proc.

> in "catdoc" (preformatted text) format.

If we want this feature, then we could probably probably generate the
catdocs with a apk install trigger? Then the catdocs would be generated
at install time of package.
 
> A screensaver needs to be able to lock the screen, and presumably

I think Williams proposal is good. Look over why the suid is needed and
check if there are better ways to do it. If there is not, then document
it in the APKBUILD.

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 28 May 2015 08:18:40 +0200

> there's probably no real reason for it.

This reminds me of a problem I have been thinking of.

When creating/maintaining package we need temporary install the build
time dependencies and when build is done we need uninstall them.

Is there a good way to do this without relying on suid? And we
definitively don't want run the entire build as root.

We probably want build the packages in a chroot too in the future.
Doing chroot(2) also requires root permission.

We currently have a magic group 'abuild'. If you are in this group you
are allowed to install packages. This means, you are effectively root
if you are in this group. Are there better ways to do it?

We could maybe tighten it up and forbid --allow-untrusted. Then you
need both be in the group and install the signing key in /etc/apk/keys

-nc

---

---

From: William Pitcock <[email-masked]>
Date: Fri, 29 May 2015 01:49:17 -0500

> need both be in the group and install the signing key in /etc/apk/keys

Ideally, I think what we should do is perhaps use lightweight
containers for build environments.  And then what you do is bind-mount
the aports tree(s) in the right places in the container.  Then you do
the build as root inside the container instead of bother with
fakeroot, cowdancer, etc.

I'm going to probably be busy with this FOSS raid monitoring stuff
this summer so I probably won't have much time to pursue this, but
it's just an idea of how it could work.

William

---