~alpine/devel

12 7

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

William Pitcock
Details
Message ID
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com>
Sender timestamp
1432632721
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20150526134643.GA1825@newbook>
In-Reply-To
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com> (view parent)
Sender timestamp
1432648004
DKIM signature
missing
Download raw message
On Tue, May 26, 2015 at 04:32:01AM -0500, William Pitcock wrote:
> 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

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

>     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???)

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/nagios-plugins
>     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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras
Details
Message ID
<20150526130438.4e59e2f5@vostro>
In-Reply-To
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com> (view parent)
Sender timestamp
1432634678
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 04:32:01 -0500
William Pitcock <nenolod@dereferenced.org> wrote:

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20150526135537.67ace052@ncopa-desktop.alpinelinux.org>
In-Reply-To
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com> (view parent)
Sender timestamp
1432641337
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 04:32:01 -0500
William Pitcock <nenolod@dereferenced.org> wrote:

> 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.

yes. i'd love to clean up this.

> 
> 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???)

!!!?

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???)
>     main/nagios-plugins
>     main/vte
>     main/xscreensaver

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.

> 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.

Yes. we should try fix as many as possible.

> 
> William
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
eleksir
Details
Message ID
<5564D539.1050102@exs-elm.ru>
In-Reply-To
<20150526134643.GA1825@newbook> (view parent)
Sender timestamp
1432671545
DKIM signature
missing
Download raw message
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.


26.05.2015 16:46, Isaac Dunham пишет:
> On Tue, May 26, 2015 at 04:32:01AM -0500, William Pitcock wrote:
>> 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
> Perhaps a workaround for grsec limits on sysfs/procfs permissions?
>
>>      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???)
> 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/nagios-plugins
>>      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.
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Orion
Details
Message ID
<20150527131901.790405cc@twinpeaks.my.domain>
In-Reply-To
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com> (view parent)
Sender timestamp
1432757941
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 04:32:01 -0500
William Pitcock <nenolod@dereferenced.org> wrote:

> 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.

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
Orion
Details
Message ID
<20150527181517.6b9bd422@twinpeaks.my.domain>
In-Reply-To
<5564D539.1050102@exs-elm.ru> (view parent)
Sender timestamp
1432775717
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 23:19:05 +0300
eleksir <eleksir@exs-elm.ru> wrote:

> Sure. Let's remove suid from sudo and su. It will be clever joke when 
> 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

> C'mon people, stop already this talks about "cleaning" system. Submit 
> 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
Bartłomiej Piotrowski
Details
Message ID
<20150527232245.0ad8a626@wallander>
In-Reply-To
<5564D539.1050102@exs-elm.ru> (view parent)
Sender timestamp
1432761765
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 23:19:05 +0300
eleksir <eleksir@exs-elm.ru> wrote:
> C'mon people, stop already this talks about "cleaning" system. Submit 
> patches, make upstream (not distro maintainers) accept them.

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

BP
Natanael Copa
Details
Message ID
<20150528080313.7c08ea9c@ncopa-desktop.alpinelinux.org>
In-Reply-To
<5564D539.1050102@exs-elm.ru> (view parent)
Sender timestamp
1432792993
DKIM signature
missing
Download raw message
> > On Tue, May 26, 2015 at 04:32:01AM -0500, William Pitcock wrote:
> >> 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.

On Tue, 26 May 2015 23:19:05 +0300
eleksir <eleksir@exs-elm.ru> wrote:

> 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.

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

> C'mon people, stop already this talks about "cleaning" system. Submit 
> 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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20150528080929.7d2ac8e5@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20150526134643.GA1825@newbook> (view parent)
Sender timestamp
1432793369
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 06:46:44 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Tue, May 26, 2015 at 04:32:01AM -0500, William Pitcock wrote:
> > 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
> 
> 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.

> 
> >     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???)
> 
> On Debian, this is an install-time choice: suid allows caching manpages
> 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.
 
> >     main/mate-applets (why would we ever give a GUI defacto root???)
> 
> Yikes.
> I'd guess this might be the same as atop.
> 
> >     main/nagios-plugins
> >     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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] installing build deps as non-root (WAS: 3.3 proposal: reduce number of SUID binaries as much as possible)

Natanael Copa
Details
Message ID
<20150528081840.44ec3532@ncopa-desktop.alpinelinux.org>
In-Reply-To
<CA+T2pCFTMLEuZjsYCbXVK7GEG3v0S9EvP5FkbboS+mKRK9_0yA@mail.gmail.com> (view parent)
Sender timestamp
1432793920
DKIM signature
missing
Download raw message
On Tue, 26 May 2015 04:32:01 -0500
William Pitcock <nenolod@dereferenced.org> wrote:

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] Re: installing build deps as non-root (WAS: 3.3 proposal: reduce number of SUID binaries as much as possible)

William Pitcock
Details
Message ID
<CA+T2pCErvhyDQSvrtTV4z1NA3+91XaBhyY-R_hcMiAR92PJ3Ow@mail.gmail.com>
In-Reply-To
<20150528081840.44ec3532@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1432882157
DKIM signature
missing
Download raw message
On Thu, May 28, 2015 at 1:18 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Tue, 26 May 2015 04:32:01 -0500
> William Pitcock <nenolod@dereferenced.org> wrote:
>
>> 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.
>
> 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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCGDVKDkgk2hAQR=b7Bbjnj9fHjQdkzrK5ANoykzav1P3A@mail.gmail.com>
In-Reply-To
<20150527131901.790405cc@twinpeaks.my.domain> (view parent)
Sender timestamp
1432917819
DKIM signature
missing
Download raw message
Hi,

On Wed, May 27, 2015 at 3:19 PM, Orion <systmkor@gmail.com> wrote:
> On Tue, 26 May 2015 04:32:01 -0500
> William Pitcock <nenolod@dereferenced.org> wrote:
>
>> 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.
>
> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---