mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael Glasgow" <glasgowNOSPAM@beer.net>
To: "Theodore Ts'o" <tytso@mit.edu>, <linux-kernel@vger.kernel.org>
Subject: Re: posix capabilities inheritance
Date: Thu, 23 Oct 2003 17:05:40 -0500 (CDT)	[thread overview]
Message-ID: <200310232205.h9NM5eOc004400@dark.beer.net> (raw)
In-Reply-To: <fa.f4bs2b4.fhub0m@ifi.uio.no>

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 >

       reply	other threads:[~2003-10-23 22:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.f4bs2b4.fhub0m@ifi.uio.no>
2003-10-23 22:05 ` Michael Glasgow [this message]
2003-10-23 22:59   ` Theodore Ts'o
2003-10-24  1:36   ` Ernie Petrides
2003-10-24  2:19     ` Bernd Eckenfels
2003-10-24  5:10       ` Ernie Petrides
2003-10-25 19:51     ` Pavel Machek
     [not found] <fa.f26d55g.1qgijbi@ifi.uio.no>
     [not found] ` <fa.hq0dft9.9i0obd@ifi.uio.no>
2003-10-24 21:24   ` Andy Lutomirski
     [not found] <fa.n4rmmgg.2423pm@ifi.uio.no>
     [not found] ` <fa.l1oevhb.1s5k583@ifi.uio.no>
2003-10-24  8:44   ` Andy Lutomirski
2003-10-24 12:41     ` Theodore Ts'o
2003-10-24 16:44       ` Andy Lutomirski
2003-10-24 20:58         ` David Wagner
2003-10-23  1:41 Albert Cahalan
     [not found] <fa.f9mv0tb.27sf3j@ifi.uio.no>
2003-10-23  1:36 ` Michael Glasgow
2003-10-23  1:57   ` Andy Lutomirski
     [not found] <fa.f36f4t9.1rg8j3v@ifi.uio.no>
2003-10-22  7:11 ` Michael Glasgow
2003-10-22 19:40   ` Andy Lutomirski
     [not found] <fa.hehull9.10mmngt@ifi.uio.no>
2003-10-21 18:24 ` Andy Lutomirski
  -- strict thread matches above, loose matches on Subject: below --
2003-10-21 11:26 Michael Glasgow
2003-10-23 16:46 ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200310232205.h9NM5eOc004400@dark.beer.net \
    --to=glasgownospam@beer.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®