> "David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said:
> > On Sat, 10 Apr 1999, Daniel Taylor wrote:
> > > On Sat, 10 Apr 1999, David L. Parsley (lkml account) wrote:
> > > > Geez, instead of overloading the meaning of 'setuid 0', let's just
> > > > use the sticky bit! I.e., sticky bit==cap flag:
>
> No overloading, please! If you do that, I can just walk in with a tarfile
> from somewhere else, or a NFS mounted filesystem, containing a doctored
> binary that grants _everything_.
No, the kernel still must perform checks before a process creates a file
with the sticky bit (=cap flag) set. Similar to the current situation
where root can unpack a setuid root binary, but a normal user cannot.
Currently, the kernel doesn't care anything about the 'sticky' bit on
files; I'm just saying let's use it for something useful.
> > Yes, we're trying to do away with the need for root; but to convert a
> > system over, you'll need to have a kernel around that supports both the
> > magic of 'setuid 0' and the new capelf stuff, so you can fire up and run
> > the system and give all your setuid root binaries the right capabilities.
> > Then you can compile your kernel without the compatibility option, and
> > viola! - root is just a user like any other. Note: you better make
> > 'getty' and/or 'login' grant all the necessary privs in some fashion.
>
> This is fine, as long as there is a way of doing what capabilities mandate
> _without_ all-powerful root (or login(8), or getty(8), or whatever) doing
> it all, or having anything to do with the whole mess. Concentrate on where
> we are going to go, when that is clear check available means of
> transportation.
This is _exactly_ what I'm trying to accomplish; by using the sticky bit
in the way I've suggested, we can effectively add capabilities to the fs
in a nicely compatible way. Think of it this way: when a process tries to
set the sticky bit on a file (=cap flag) or create a file w/ that bit set,
the kernel reads the capabilities from the elf headers and applies the
same checks as if the process were trying to set caps in the fs (as we'll
have with ext3). So me, as a simple user, can't just unpack a tar file
with a capability-enabled binary. Also, by making a capability-enabled
file immutable, we insure that the file owner can't set caps at will;
first they must un-set caps, then apply changes, then re-set where the
kernel will check the caps again.
I'm going to write another itterration of 'caps in elf headers now' and
try to put my complete idea all in one place in final (mostly) form.
> --
> Horst von Brand vonbrand@sleipnir.valparaiso.cl
> Casilla 9G, Viņa del Mar, Chile +56 32 672616
>
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/