Horst von Brand <vonbrand@inf.utfsm.cl>:
> [Filled for readability]
>
> "Linda Walsh" <law@sgi.com> said:
>
> [...]
>
> > There is no non-determinability here. Init sets initial luid. Run
> > level scripts set initial CAPs. Only root on physical console gets full
> > CAPs. If MAC and file-caps are in, management gets real easy/non-kludgy.
> > Doesn't matter if you crack root password -- you need to be on the
> > console. Doesn't matter if you get a root-shell through a daemon, the
> > daemons wouldn't run with unnecessary caps and wouldn't run with a MAC
> > label that allows them to modify system security files. For example,
> > /etc/passwd is labeled with Sensitivity=00, Integrity=250. Everyone can
> > read it, but only processes running with Int=250 can write to it.
> > Default for 'root' is running at 'int=10' (say normal users run w/int=5).
> > It doesn't matter what root-level process they came in on, none has
> > privilege to write to /etc/passwd. /etc/shadow can be set with sens=250
> > and int=250. Same thing -- default root runs at sens= 10.
>
> Interesting idea. Is this a standard? How does it interact with UID/GID?
Depends on whose standard - this came out of the B1/B2 trusted environments,
and there is some equivalent in the Common Criteria (somewhere, I'm not
fully familiar with CC to be able to say where).
UID and GID work just as they do now. These are DAC labels and not MAC.
> > Only a login @ console can root log in and gain sens=250, int=250. Root
> > ID daemons don't (they run at 5,5 or 5,0). Root deamons don't run with
> > CAP_MAC_OVERRIDE -- again, console only function.
>
> How do I change my password then?
The trusted computing base has to contain an executable that has sens=SYSLOW,
and int=250. When that image is executed it would run at the labeled
sensitivity and integrity level, which would allow it to update the shadow
file. This is why the filesystem must support MAC. Also note that the
image would be labeled SYSLOW to prevent any modification, and allow any
user to run it. (In the listed environment where normal users are int=5,
root int=10, then anything below 5 could be used to store the executable).
It also usually gets a security capability to allow it to cmplete the
password change if changing the sensitivity level to 250 is required.
In theory, anyone could even read the executable, copy it, make mods to it,
but the copy would no longer be labeled properly to modify the shadow file.
I could be off a little in the details, but this is the gist of how passwords
are changed.
> > Such a security system really shuts down crackers fast -- they
> > break in but have no privileges. The damage they can do is limited.
> > They couldn't even write or read root's home directory even though they
> > are UID==0. Major impediment.
This has been very succesfull in UNICOS environments (and trusted X where
X is Solaris, IRIX, HP-UX...).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:13 EST