Re: caps in elf headers: use the sticky bit!
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 13 Apr 1999 08:53:50 +1000
David L. Parsley writes:
> Hello!
>
> On Sun, 11 Apr 1999, Pavel Machek wrote:
>
> > Hi!
> >
> > > Geez, instead of overloading the meaning of 'setuid 0', let's just
> > > use the sticky bit! I.e., sticky bit==cap flag:
> >
> > People/old programs do not realize that sticky bit means elevated
> > privileges. Which is bad from backwards-compatibility point of
> > view. I.e. I go to my sysadmin and ask him to set sticky on one of my
> > executables. He'll do so.
>
> Yes, this could be a problem, if the sysadmin doesn't know he's running a
> capability enabled system where the sticky bit enables caps. Any sysadmin
> worth his salt, though, should wonder why a user can't set his own sticky
> bit, and why the user would ask it be done.
>
> > > - To set the cap flag, a user (process) needs CAP_SETFCAP raised, and the
> > > kernel (besides the normal fs checks) validates the cap headers as well
> > > for legality. (this also applies to creating files with this flag raised;
> > > i.e., through a copy operation)
> >
> > You do not want this kind of support in kernel. Believe me.
>
> Got a better reason than 'believe me'? Like, 'there's no way to code that
> into sys_chmod'?
>
> > Better use
> > setuid0 as marker (those are already immutable) and userspace suid
> > program which implements your CAP_SETFCAP.
>
> Here are the problems I have w/ marking w/ setuid0: screws up fs
> stuff; ls et al. don't show a file is actually owned by another user
> when it should be, and quotas don't work right, either; according to
> the vfs, root owns all cap-enabled files; storing the 'real' uid and
> suid bit in the caps are uglier, to me, than hacking the sticky bit.
> Marking with setuid0 just had too many ugly repercussions that I
> found myself having to work around to fully specify a sane structure
> for caps in elf headers.
All of these are non-problems:
- ls can be updated if you want to see who the original owner
was. Note you *only* need to change ls
- the number of privileged binaries is so small that accounting them
in root's quota is fine. Besides, these binaries *are* special, and
there is no strong reason to "charge" them to the quota of the
originating user. Also, most of these privileged binaries are still
going to be made by root.
> Please give a little bit of thought to the sticky bit idea, and look at
> the problems with it and solutions suggested.
Overloading the sticky bit is just plain broken. It opens up a
whopping big security hole. It just cannot be used. End of story.
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/