In article <3910D72C.6D44FD65@sgi.com>,
Linda Walsh <law@sgi.com> writes:
> Ton Hospel wrote:
>>
>> 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.
> ---
> Whether or not userid's are roles or users is a *system policy*,
> not a kernel policy.
It's not a policy, it's a model of reality. Users are these flesh and
blood things, while userids are states of a piece of electronic equipment.
So if you want this mapping, you really have to WORK to make it true.
The sheer amount of Draconian measures you MUST introduce is a sign that
it's an unnatural model. Sure, you can FORCE it to work, but only by
forbidding a lot, and assigning blame to the wrong person when something
goes wrong.
>>
>> 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
> ---
> Sounds right...
But in reality user V changed B's .login scripts. V is guilty by subverting B.
You completely missed the RELEVANT event, which is not that U executed X,
but that A switched to B (and then executed X)
(More Draconian rules snipped that you HAVE to introduce to make the
model work)
>> - 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 Xm
> ---
> That's yet another Policy Model (YAPM(tm)) :-). It's not the
> policy required by CAPP. The purpose is people take a known quantity
> like a CAPP compliant system and can then define their own system and site
> policies from there forward. It's like starting with the UNIX98 standard
> or the Linux Standard Base -- its a well-defined and known starting point.
> You also are either in compliance with the standard or not. No one is
> saying UNIX98 or LSB is *the* single and only and best way to do things.
> It is merely a "reference" point.
>
But my proposal logs relevant points yours completely misses. That
indicates not that it's just another system that does not happen to
follow CAPP, it indicates CAPP is BROKEN. The A to B switch is THE MOST
relevant event that should be logged here.
>
>> 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).
> ----
> The proposal includes a session id for exactly the reasons you
> mention even though CAPP doesn't require it.
>
>> 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.
> ---
> Then how does a program like 'login' set it if there is no
> kernel interface to it?
It doesn't. ALL uid/gid switches get logged. Whether you call the program
login or not.
>
>> You don't need
>> to change all login style programs to set a audit id (where you'll
>> probably miss some.
> ---
> No -- you set it in PAM. System Policy - any programs that are
> not PAM compliant will not be used for access to the system.
>
Normally PAM is a tool to make life easier for programs needing
authentication, not the one and ONLY way to get something done as
a user. If you want that, you should extend PAM to
authenticate every uid/gid switch, or again you will miss things.
The whole "login" thing is a red herring. It's an artificial concept.
When do I log in ? when I allocate a tty for me ? when I detach my
process group ? when I switch my uid ? when I write my utmp record ?
when my password/retina gets checked, and the token is told to the kernel ?
Lots of programs do PARTS of these steps. It's purely taste if you call
them "login" programs or not. is inetd a login program ? it runs demons
for users. Is .forward a login program ? .ssh/authorized_keys ? gnuserv ?
apache ? xterm ? imap ?
> Every commercial system vendor *already* has a C2 feature
> compliant system that supports this type of auditing. You want to
> tell me that non of those system vendors are running Unix. Puh-leeez.
> Sun, HP, IBM, SGI, SCO...etc -- even NT! All (except MS) also have
> B1 compliant systems. Linux is a "no show" in both categories.
So ? Does that mean it is a good model ? If we use number of installed
systems or popularity as a measure, windows is a VERY good system.
All it means is that there is a standard that you need to follow for
contracts. and that these companies are into contracts, not technical
excellence.
I never said it isn't done. I say that the proposed way to get to
the result is misguided.
>
>> 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)
> ---
> Sorry...I know on my secure system, each UID is backed by
> exactly 1 retinal scan -- a real person. I have "trust" in my system.
> You have your system. They can both exist in the same kernel.
Sure, and you completely missed that V fooled B in my example. You just
arrested X. And you KNOW X is guilty, because the CAPP compliant logs say
so, and you have all these retinal scans and stuff, and all login
programs are heavily authenticated.
>> Then realize you should log the reality, not your preferred interpretation
>> of reality.
> ---
> Maybe you'll learn reality is a *subjective* experience. Everyone
> experiences it through their own private filters. What makes for a
> fun reality is an acceptance of other people's realities and not making
> them wrong for having their reality (unless it directly stomps on you).
> If all of this is a build *and* run time option -- why do you care?
> You can create your own distro that only uses the sessid -- I'm providing
> building blocks -- not a design for your system.
Nope, reality is an objective thing (by definition).
It's basically that what remains when you stop believing in it.
It's how you experience reality where things become subjective.
The uid switches really happened. And in the example there is a chain
leading from user U to program X. But if you only watch the endpoints,
(log that U did X), you will miss that the inbetween links are the ones
that are broken (V subverted B).
Notice that my model does not enforce CAPP, but allows it. So if you
are happy with CAPP, and want to sell it, it allows you to (I won't be
working on your system anyways, so I don't care. But it allows me to
also implement the interpretation I like). It leaves the model (or policy
if you prefer) out of the kernel.
Best implementation of CAPP in this model is a trusted demon
(or better, a completely seperate secure machine for logging) that
gets the kernel events, has its own database of the CAPP state of the
system and regularly checkpoints that, and also writes an event log.
By having the demon essentially work as a database you avoid the one
problem that was brought up in another mail, that you prefer not to
depend on an audit trail that can need to go back arbitrarily far on
a long running system (though in a sense it's unavoidable. Some
of the events you're auditing really HAVE that long a history. You
just cannot encode a chain in a single link).
-- Nothing is impossible to the man who does not have to do it himself!- 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