Re: posix capabilities inheritance

[Michael Glasgow]

Theodore Ts'o wrote:
> I agree this is safe, and allows the use of your setuid wrapper
> script.  The one reason why I think it's better to modify programs is
> that it's too easy for individual system administrators to screw up
> the configuration used by your wrapper script, and accidentally
> introduce a security vulnerability into their system.  It's dangerous
> to give a program some capability (or reduce the capability given to a
> program designed to be setuid) without examining the source code and
> being clueful.  So by making the program setuid and editing the source
> code to add an explicit capability drop in the program is much, much
> safer compared to having a random system administrator to edit a
> config file and trust that he or she does so correctly.

I can see your point, but I guess we'll have to agree to disagree.

Even with selective capability inheritance enabled in this fashion,
it is still possible to avoid using it and modify programs directly,
if you think that's more secure.  Personally, I think that in some
cases it's slightly more secure to have a very small (statically
linked) setuid wrapper program which sets up capabilities properly
than to make a very large program setuid-root (when it was not
designed to run as root), only to add one capability.

Yes, you can do the capability-setup first thing in main()... but
this is occasionally insufficient.  Also, it makes it a pain to
have, for instance, a backup user with CAP_DAC_READ_SEARCH who is
able to run several apps, e.g. dump, tar, cpio, rsync, etc.  from
a restricted shell.

The code to drop privs is not hard, but it's also not trivial.
Those without a clue are just as likely to screw it up as they are
a wrapper; and anyway since when did it become a design goal for
the kernel to cater to the ineptitude of the clueless?  That sounds
more like a Redmond, Washington philosophy than one fit for Linux. :-)

--
Michael Glasgow < glasgow at beer dot net >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/