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