Either you will have an ext3 module loaded, and therefore have
access to the capabilities as well, or you will not be able to
mount the filesystem.
The filesystem module itself can be written to fail-safe if it
is loaded into a kernel that does not have capability support.
For "backwards compatability" with existing security scripts it
could have a mount option to show all programs with capabilities
enabled as SUID.
On Wed, 7 Apr 1999, David Woodhouse wrote:
>
> weejock@ferret.lmh.ox.ac.uk said:
> > On Fri, 2 Apr 1999, Pavel Machek wrote:
> >
> > > > > 1. Put capabilities information in the executable header.
> > > > > 2. Mark the executable setuid root.
> > > > > 3. Have the kernel check for #1 if #2, and prefer #1 if present.
> >
> > > Old security scripts program has root privileges. It is wrong, it has
> > > only subset. But it is wrong _the right way_. Old scripts still see
> > > the "bad scenario".
> >
> > > It is no-loose situation.
> >
> > It's a no-lose situation until you start using the new features to add
> > privileges which weren't there in the first place.
>
> That's not the common case, though - the first things that get converted to
> use capabilities will surely be the existing suid stuff, won't they?
>
> Are you suggesting that the whole system should break when you reboot to an old
> kernel?
>
> What wrong with sticking
> if (geteuid() == 0 && getuid() != 0) exit(1);
>
> in your new capability-aware utilities if it's so important to avoid suid
> operation on old kernels?
>
> A lot of people are going to want to remove the suid bit from existing
> executables and add capabilities. If that then breaks when they reboot to an
> old kernel, then we've done something blatantly wrong. Using the suid bit as a
> marker to show the presence of a 'capability header' seems like an ideal
> solution, because it provides backwards compatibility without any loss of
> security in relation to the _existing_ situation. New capability-holding
> utilities that were never suid and should never be suid can just include that
> one-liner I gave above.
>
>
>
> ---- ---- ----
> David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
> Project Leader, Process Information Systems Mobile: (+44) 976 658355
> Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
> finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
>
>
>
> -
> 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/
>
-
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/