In article <390F505E.6CDBE3A6@sgi.com>,
Linda Walsh <law@sgi.com> writes:
> Alan Curry wrote:
>
>> Linda Walsh writes the following:
>> > If we changed the login id to 'root', we'd tend to lose track of who the "real" user was who logged
>> >in and "su"ed.
>>
>> Why do you think the `real uid' is called what it is?
>
> ---
> It is fairly trivial to write a suid program that somehow gives one a shell as another password -- no
> login or 'su' or password required. In fact I may *want* something like sendmail to run as my userid
> when it runs my mail filter, but that doesn't mean it really is ME running the the program -- it
> was run by a deamon. Same thing with an "suid" program. It could change my real and effective to
> something else. That doesn't mean I authenticated as that person.
>
>>
>> Because that IS the real user. If you used su, you REALLY ARE who you su'ed
>> to. The previous uid is NOT REAL ANYMORE. If you want to believe otherwise,
>> go ahead and bloat your own kernel, but please quit trying to push that crap
>> into mine.
>
> ---
> Your login is *your* identity on your system. Some signons like 'root' are not a person but
> a 'role' or a way of obtaining privilege. That doesn't mean you are now the *person* named "root" -
> there ain't such (disregarding anyone who is actually named 'root', but do we really think it that
> person who has logged on everytime we see a 'root' login? Of course not.) . CAPP requires
> the audit-id to be tracked corresponding to who was "authenticated" at the point the system went from
> being "closed" to "opening" an authenticated session. "O_AUDITING" calls for individual accountability
> (i.e TOE "users") whenever security-relevant actions occur. This component requires every auditable
> event to be associated with an individual user." [not User ID]
>
Aarg, I really have to speak up.
Sorry, but no, Alan is right.
In a sense ALL unix userids are roles, and shouldn't be confused with
persons (ever noticed one person having multiple userids, and one
userid being used by multiple persons. I did). Trying to create such a
concept will force you to destroy unix semantics until it's not unix
anymore.
What you would seem to like is (if X is a program we want auditing for):
if:
person U logs in as A, switches to B and executes X
Then:
The system logs user U (represented as his session number at login) executed X
But that concept is flawed as you can see in many ways:
- if you switch using su, you can follow the user, if you switch with
rlogin/telnet/ssh you loose track of B, and see a new B arriving who
executes X. Why should it matter HOW U switches user ?
- - When he is B, U queues a crontab job that does X
Again, X is assigned to B (or to the crontab user).
In a previous discussion you suggested maybe turning of crontab
(Warning, warning. Attempt to make unix less useful in the name of
security). Suppose you do ? does that solve it ? NO ! E.g. If I'm B
and I can't use crontab, I'll write my own always running demon that
just sleeps and uses a config file to execute jobs. U can use that
instead. I'm also not allowed to run daemons ?
- U makes a .forward for mail with a |command,
then sends mail to B. Turn of command execution in sendmail ? there
goes my procmail.
- U puts a file in ~/cgi-bin and accesses the corresponding page on
apache. Oops. So we forbid apache UserDir ? what, and I can't test
my cgi-bin scripts anymore ?
- U makes a connection with user B's emacs gnuserv
- U puts X in any of my login scripts, and waits for B to log in
- U changes B's .rhosts, and use rlogin to B
Turn of rlogin, it was insecure anyways ?
- I make an .ssh/authorized_keys that executes a command on certain
connections. Was ssh also insecure and should be turned off ?
How do you know it was user U in the first place ? (this is the KEY question)
If I'm A and operator, and am curious about B's thesis (filesystem protected),
I might switch to root and then to B and print the file. To who should we
honestly send the printing bill ? To A !
If I'm A and operator, and B calls me that he forgot hist thesis
(filesystem protected), please print and bring it, I might switch to
root and then to B and print the file. To who should we honestly send
the printing bill ? To B !
The whole abstract concept who REALLY does something cannot be solved
purely technically.
About anything is a better idea.
E.g create a session id that starts at ANY uid/gid switch (and
duplicates under fork/exec). Also log which program did the switch,
from which session to which user. For the example mentioned in
the beginning this would log:
- login switched session 0 (implicit root) to user A creating session M
- su switched session M (known to be user A) to user B, creating session N
- Session N (known to be B) executed X
This is MUCH more useful since it does not make the silly assumption that
you should associate the login with who does something (e.g X was
really executed because Y changed B's login files, and the unsuspecting U
now triggered it). It allows an audit to concentrate on the intersting
points, that is the ***uid*** switches. In many cases you will now have to
interview U AND the persons B is assigned to,to understand what really
happened (also true in ALL auditing methods)
With a simple program you can follow back X to the login of user A (who
you assume is an authenticated person U). So you can even have your C2
checkmark to sell to the government.
Is this really different from your proposal ? YES !
Sure, it needs a mechanism to export the log data from the kernel, and
even a session concept (that was needed anyways if you want auditing).
But it does NOT need the introduction of a audit userid, or a syscall to
set it, since no program has in fact the right to set it. You don't need
to change all login style programs to set a audit id (where you'll
probably miss some. Quick, how many of you thought of e.g. xdm ?).
Let's not even mention the cases where I fool a setuid root program to do
something as a user (e.g. inetd), which makes it implicitely a login.
I'm not saying that this is the way to go (made it up on the spot) but it
can hardly be more misguided than your idea, which tries to retrofit
something on UNIX which just doesn't in fact fit.
Before going to sleep each night, chant 3 times:
"the userid IS the real user, anything else is a figment of my imagination"
until it sinks in.
(e.g. you assuming that the first login as A was in fact by U)
Then realize you should log the reality, not your preferred interpretation
of reality. The interpretation is the job of the sofware processing the
audit records (where for all I care you can choose the misguided C2
interpretation)
-- There is no place like ~- 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:13 EST