Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/28/2010 04:14 AM, Pekka Pietikainen wrote:
> On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
>> This feature is now approved and I see bugs get filed.  The documentation and
>> guidelines are very incomplete.  How does one figure out which file
>> capabilities are needed by the programs I maintain that currently use setuid? 
>> Help, please.
> Probably: remove setuid bit, run, see what breaks. strace may be useful
> 
> [pp at the ~]$ strace ./rsh localhost 2>&1|grep EACCES
> bind(3, {sa_family=AF_INET6, sin6_port=htons(1023), inet_pton(AF_INET6,
> "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES
> (Permission denied)
> 
> -> needs CAP_NET_BIND_SERVICE. It didn't seem to output any error to the
> user, so the lacking permissions may be well-hidden.
> 
> https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setuid
> seems to have a list btw., which may or may not be correct.
> 
> Do note that removing suid from some programs is a bad idea:
> "Warning: Do not use it, because mount and umount can not do some checks,
> then users can mount/umount filesystems that do not have permission."
> (probably those checks could/should be implemented upstream, if they're not
> already there)
> 
> So it's a feature that could introduce new vulnerabilities
> if done wrong, but it's certainly worth doing, carefully. If uncertain,
> ask.
> 
> 

I think we can refine this as we go.  Steve Grubb is a great source of
information on handling capabilities.  One other goal of this is to find
the apps that need full setuid and update rpmlint/whitelist with those
apps.  su, sudo, ksu, userhelper all need full setuid (capabilities).

If your setuid app is covered by SELinux policy we know in the rules
which capabilities are used in the application, so you can work with the
SELinux team to get the list.   In some cases you might have
capabilities that you do not need.  For example newrole needs to send
audit messages, (cap_audit_write) but when we coded it up originally it
was setuid root, and started as root, then executed the setuid(USERUID)
call, requiring the cap_setuid capability.  Then it dropped capabilities
requiring additional capabilities.  By moving the code to file
capabilities, I was able to give it just cap_audit_write and drop the
code to change the setuid and drop capabilities, eliminating the need
for these capabilities.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzJa2oACgkQrlYvE4MpobNMWQCbBHT664Rillc8ja/6MdvLVC94
HVwAoKUlyvb2+QXIIhXzB4DeSuXSRyKF
=4Wuk
-----END PGP SIGNATURE-----