> > - extra section holding priviledge data, only used by newer kernels
> > [this is your solution], plus:
> >
> > - new kernel 'fakes' a setuid root bit, so these binaries can be easily
> > identified even with old (priviledge-unaware) 'ls'. (The executable
> > bit is not touched.)
>
> What I do not understand is when new kernel is going to store this
> information? There are executables which have capabilities
> headers. Some of them have to be trusted, other not. Where is new
> kernel going to store this info?
root owned? If root was able to write it then it was in a priviledged
position at the creation time of the binary. (so it could have created
whatever other 'trusted-bit' too.)
but alternatively we could use the setuid root bit too, this has the
downside that these binaries will possibly have too much priviledges under
older kernels - i dont think this is an issue, the system is still usable.
This second method has the advantage that we can disallow the creation of
the setuid root bit for a system easily.
[the 'fake setuid bit' will not be there for the second method, but for
networked filesytems we might want to drop it. (or not, it's a filesystem
policy)]
to sum it up: to have Linux capabilities without a capabilities-aware
filesystem the binary has to have the setuid root and executable bit set,
and a special section further finegrains capabilities. (a nonexistent
special section [ie. old setuid root binaries] means 'all capabilities are
raised for this binary'.) Old kernels can still execute these binaries.
File utilities can see 'dangerous' binaries. (the fcntl() might further
help to finegrain information about a trusted binary)
this makes the whole thing pretty robust i think, because setuid root bit
handling can assumed to be rather safe under Linux, and the capabilities
section does not give any special rights, it actually restricts them. (so
if whatever goes wrong with the section-stuff, it will most probably not
be a security hole, compared to old setuid-root binaries.)
(note that this method enables us to get rid of root completely in the
future, even without filesystem-based capabilities! being able to set the
setuid root bit is [should be?] a capability itself, root does not
necessarily has to have this right. This breaks symmetry a little bit but
i dont think it's a problem.)
-- mingo
-
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/