On Wed, 3 May 2000, Steve Dodd wrote:
> On Tue, May 02, 2000 at 11:01:38AM -0700, Linda Walsh wrote:
>
> [.. ugh, bad line wrapping, ugh <g>]
>
> > One of the requirements for this level of 'trust' is that audit actions be
> > able to be written corresponding to the appropriate 'authenticated' (as in
> > they gave a "password" (literal password or other biometric)). Currently,
> > none of the uid values can be guaranteed to remain constant for
> > a login session. Thus the luid fix.
>
> I'd rather see ruid "unbroken", but probably isn't possible to do this and
> retain compatibility. Other than BSD style euid<->ruid swapping (which
> could surely by fixed by a "local" kludge, rather a global one <g>), the
> issue is su and friends. I've never been entirely happy with the Unix "become
> someone else to do certain things" model; I'd much rather remain user "steved"
> but "assert" or "raise" particular privileges when I was going to something
> dangerous. Doesn't VMS have something like this? set proc/priv=xxx?
Yes. A process has two privilege masks: currently enabled privs, and
maximum privs. (I forget the exact terminology.) A process can turn on
any of the privs in its "maximum" set, and turn off any that it has, at
any time, and there is indeed a DCL (shell) command to do this. The
process' priv masks are set from the user's UAF (/etc/passwd) entry when
the process is created, so they're based on user identity.
A process may acquire additional privileges when running an image
(program) that is "installed", but those privs are taken away when the
image exits. (Here "install" doesn't mean "copy to the executables
directory", but refers to an operation that requests the kernel to hold a
file open and record other information about it, such as amplified
privileges. INSTALLed files cannot be modified or replaced until they are
unINSTALLed. The only place these "amplified privileges" are recorded is
in kernel memory.)
A process holding the SETPRV privilege may set any privilege it wants. A
few others (CMKRNL for example) effectively allow you to get SETPRV since
they give you access to the privilege database. This set is documented,
so you know what not to hand out to untrusted users.
In VMS, the user always remains who he logged on as, and a known set of
programs manage high-privilege stuff. Of course you can audit privilege
transitions, INSTALLs, etc.
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu "Where's the kaboom? There was supposed to be an Earth-shattering kaboom!" -- Marvin Martian, 01/01/2000 00:00:00- 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 : Sun May 07 2000 - 21:00:15 EST