| Summary: | Way too many SUID root programs | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Daniel <d_lord> |
| Component: | Misc | Assignee: | Gentoo Security <security> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://nopaste.php.cd/24439 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Daniel
2004-08-04 11:37:52 UTC
With that find command you'll find not only programs which are suid to some other user than root (which is still bad, but nearly as much as UID 0) and dirctories which have the sticky bit. Calling the latter a security issue by default is a bit harsh, IMO. Oh, and there are programs which enhance security by being suid root. gpg for example. Ok, you may add a -type f to the find command. And yes it may be a good idea to let gpg be set suid root. But why not let the user decide? Or just drop a note while emerging? Thos notes tend to get lost. While there is no accepted mechanism to make sure all einfos are read... I don't know, I'd feel uneasy both ways. There is nothing that the Security Team can do to solve that problem as a whole. Some (most) of the programs that have the root SUID set need it. You will break them if you don't have it. So it's a reasonable default to have it set for these packages, and you still have the option of removing it (and break the corresponding packages). If you identify a specific package that has unnecessary root SUID programs, please file a bug for that package (component = Ebuilds) specifically, that way you will be able to convince the package maintainer that this is superfluous. If you want a global "suidroot" USE flag and want to have every ebuild conform to it, you should bring up a discussion on the gentoo-dev mailing-list and try to convince Gentoo Developers that it is a good idea. Because if it's not accepted by all or part of Gentoo ebuild policy, some ebuilds will not respect it and it won't be useful. There is an undocumented feature called suidctl which will remove the sbit from every app at install time unless it's in the allowed list which is defined in /etc/portage/suidctl.conf
mkdir -p /etc/portage
echo '#' >> /etc/portage/suidctl.conf
FEATURES=suidctl emerge beep ; # for example
>>> Preforming suid scan in /var/tmp/portage-pkg/beep-1.2.2/bin
>>> Removing sbit on non registered /usr/bin/beep
>>> Appending commented out entry to /etc/portage/suidctl.conf for beep-1.2.2
ls -l `which beep`
-rwx--x--x 1 root root 10048 Aug 4 17:10 /usr/bin/beep
That should give you the fine grained control your looking for.
Thanks, thats exactly what I'm looking for. |
