lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Capabilities, this time in elf section
    David L. Parsley writes:
    > Hi Albert,
    >
    > On Thu, 15 Apr 1999, Albert D. Cahalan wrote:
    > > > haven't really given more than a few second's thought to the solution,
    > > > evidenced by your misunderstanding about the immutable bit relationship.
    > >
    > > I'm not some kind of vegetable you know... (rudeness not appreciated)
    > > While I think you are terribly wrong, I acknowledge that you have given
    > > more than a few second's thought to the solution. I have too.
    >
    > Not everybody has done their homework on this stuff before speaking
    > up. I now see that you obviously have done the required reading.

    Maybe I'm wrong, but the impression I've gotten from you, David, is
    that whenever a new person pops up into this debate and disagrees with
    you, you tell them they're ignorant (not reading beforehand, not
    thinking, etc.).

    Like I said, maybe I'm wrong, and maybe it's just my perception, but
    even so, you might want to run a self diagnostic and see why you are
    giving that impression.

    > > > Albert, in particular you don't seem to understand just how important the
    > > > inheritable bits are in a capability-based security system, and how bad it
    > > > is to not require setting them to be priviledged. Or at least, if you
    > > > want it to be priviledged, now you have to mark it setuid root.
    > >
    > > Which inheritable bits, file or process?
    >
    > File.
    >
    > > It would be very bad to let a
    > > user set or clear bits in either one.
    >
    > Right, but so far (according to my threads with Richard Gooch and
    > Pavel Machek) any file that isn't setuid-root will still have it's
    > inheritable bits honored. This would mean any file could inherit
    > rights from the admin. With the sticky bit solution, a paranoid
    > admin (or distribution maintainer) could configure the kernel to use
    > default inheritable of 0, and only honor inheritable on a file that
    > has been capability enabled. (which in this system is a priviledged
    > operation). Yes, the distribution maintainer would have to set caps
    > for _every_ file with a legitimate right to inherit caps, but I
    > think it would be great to be able to do that. An admin would be
    > virtually immune from trojan binaries on the local fs. ('sl -Fla'
    > anyone? ;-)

    I've not responded for days because I've been busy, not because I feel
    your argument "blows away" the suid-root scheme.

    You want privileged inheritable bits, fine. You can do that with
    suid-root or with sticky+immutable. After all, the inheritable bits in
    both cases are stored in the CAP ELF header. So to solve the security
    problem, you drop privs on exec if they're not in the inheritable
    mask. And you don't allow lusers to modify the inheritable mask.

    IIRC, Pavel was suggesting lusers can modify the inheritable mask. I'm
    not supporting that.

    Where I think you are concerned with the suid-root scheme is that it
    implies /bin/sh must be suid-root if you want it to inherit the caps
    of a calling god process. I don't see a problem with that. Whether
    you have a suid-root or a sticky+immutable magic flag, either way,
    /bin/sh *is* special.

    Now, I think that you think that a suid-root /bin/sh implies that
    when you run a non-caps kernel, a random luser then does /bin/sh and
    boom! Crack, crack, crack.

    Well, this isn't the case. If you read one of my earlier messages, I
    suggested putting the suid-root+CAP ELF header stuff into user
    space. So that means when you run the setcap programme, you either
    edit the binary (if it's statically linked) to insert some magic code,
    or ensure the dynamic linker has the magic code.

    This magic code does all the work of raising caps if euid=0, if the
    kernel has caps, and then sets euid to the stored euid in the
    header. On the other hand, if the kernel doesn't have caps, the magic
    code can elect to refuse to run the binary, or to set euid=uid, or
    whatever.

    This means you can safely switch between a caps-enabled and a non-caps
    kernel. You can elect, on a per-binary basis, what should happen when
    running a privileged binary on a non-caps kernel. This gives
    incredible flexibilty, allowing a sysadmin to configure the level of
    paranoia they wish.

    This scheme also has the advantage of running over NFS, CODA, ISO9660,
    AFS and so on. You can run a special auditing programme at boot time
    if you want to check the integrity of the dynamic linker, for extra
    paranoia.

    And best of all: it's all in user space!

    > > It is perfectly fine to use the
    > > setuid bit to mark any "interesting" files, and a very good idea too.
    > > Safety is ensured by the mangled header.
    >
    > Well, yes, you can mark cp, tar, etc... as setuid-root, and that would
    > work just fine to securely set inheritable bits. But this is a
    > compatibility nightmare; don't _EVER_ boot to an old kernel. Eric
    > Biederman suggested the immutable bit specifically to make it safe to boot
    > to an older kernel. You also don't want all these extra setuid-root
    > binaries on a remote-mount fs.

    Those suid-root binaries will be quite safe, because of the magic code
    that gets run before main().

    Regards,

    Richard....

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:3.296 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site