allbery@kf8nh.apk.net wrote:
> | > I'm not talking about limits. I'm talking about an
> | > auditting ID that needs to be based on a when a user logs in
> | > and stays with them over any SUID or 'su' commands.
> |
> | "telnet localhost" subverts this if you allow it (but you probably
> | wouldn't).
> |
> | This shows that you have to audit and possibly restrict all daemons that
> | permit uid changes anyway.
> |
> | So why not just use the time-honoured "real user id"?
>
> I think you're misunderstanding; this is a "new idea" only for Linux.
> LUIDs are part of CAPP, which used to be called "C2" security. IOW
> it's an existing standard, and one that some places insist on.
Ok, but what's the point? There is a perfectly functional "real user
id", and since you have to audit daemons to ensure LUID is properly
tracked according to your preferred definition of "session", why not
just ensure that the ruid tracks the same way. I.e., just use ruid and
call it LUID for CAPP purposes.
If you're thinking about capabilities to restrict LUID changes to the
select few daemons (e.g. just "login" and then only via a physical
console) -- well, once you've gone that far, the ruid isn't used for
anything else. It's available for use as the CAPP LUID :-)
And there's always the session id, but I never understood what that's
for, in the midst of all the controlling terminal / process group id /
process group leader quagmire.
have a nice day,
-- Jamie
-
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 Apr 23 2000 - 21:00:09 EST