Ton Hospel wrote:
> 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.
--- Whether or not userid's are roles or users is a *system policy*, not a kernel policy.I may choose that all users have 1 userid for which their login password is a PAM module that does a retinal scan. I can then allow accounts to also have a regular password that is used for 'su'. No semantics broken so far.
> > 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 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, --- Not if I require another retinal scan to be sent via a physically secure network connecting the machines. Policy: no logins w/out retinal scan.
and see a new B arriving who > executes X. Why should it matter HOW U switches user ? --- 'su' we define to be a temporary role switch that doesn't require a retinal scan -- another policy decision.
> - - 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). --- At a secure site -- you are assuming everyone has the freedom to do what they want. This may not be the case. Another option would be to mount user writable partitions 'nosuid'.
> 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. --- Ok, you do that. If you are "B", to start your deamon, the daemon's actions will be recorded back to what person's retinal scan was used to start the login session that started the daemon.
> U can use that > instead. --- That's ok...because "B" is now running proxy service for anyone who wants to use "B" as a patsy. If "B" is fine with that, then he can be dragged off.
System policy under CAPP specifies default file permissions should use a umask of 077. CAPP also specifies that any change of access rights must be audited. So "U" still requires "B"'s complicity -- and that's ok, cause if we drag off "B" and he's ok with taking the fall by himself, at least "U" will have lost their "in".
> 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. --- Nope -- luid would likely be 'deamon', euid is 'B'. So something goes wrong we ask why 'B' why he had a sendmail script that compromised anything.
> - 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 ? --- Another assumption -- that my secure system is going to have an apache server. But again, system logs luid of deamon (maybe a user 'httpd') and user id of the script owner. Remember, by default programs created by users are masked 077 -- changes to this are logged. Umask may be disabled for users. Calling system call 'umask' is also audited.
> - 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 ? --- User 'U' can't write into a directory owned by someone else unless 'B' has broken system policy and allows anyone to write to his directory. As soon as the audit deamon detects a potential break in security policy, an admin can be notified. Some user's could be selected in a configurable audit to not have this recorded, but CAPP policy specifies recording this data for all users.
> - I make an .ssh/authorized_keys that executes a command on certain > connections. Was ssh also insecure and should be turned off ? --- Depends on your site and system policy. Me, I'm satisfied that the remote sshd calls pamd which asks pamd on my system to rescan my retina, but some people may choose to allow or disallow it. Depends on the policy that is implemented. CAPP specified a particular Protection Profile that is to be implemented. What and How events are audited are defined in that Policy. None of the cases you describe are any sort of problem on a properly configured system.
None of this needs to affect *you* as an individual. You can choose what policy you want on your system. You may see CAPP as too restrictive. A business or government institution may not -- they may feel those restrictions are worth the increase in "Trust".
> > 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 ! ---- System Security auditing is not designed for accounting/billing issues. To whom do you send the printing bill? Maybe "A" has a 2nd signon (not under a CAPP compliant system), but in a student setting, signon A could be for "Accounting Class" and B could be for her "Biology" thesis work. In that setting you want it charged to "B". But this is not a CAPP compliant setup.
> 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 ! --- You are describing a Student/University environment which would likely have a very different security policy than the NSA. If this was a 'secure' facility, it would be against policy to be so laissez faire with regards to over-riding system security. It also would be an auditable event that likely would attract attention as it would be a violation of normal security policy.
CAPP defines specific requirements for a specific environment. It's not designed to solve every billing and security problem under the sun.
> The whole abstract concept who REALLY does something cannot be solved > purely technically. --- Of course. System policy defines security. Auditing and luid's merely support enforcement of certain types of policies.
> 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 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.
> 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?
> 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.
> 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. --- Bugs are to be fixed/addressed in a timely fashion under CAPP. They are not part of the system design or system policy -- just like earthquakes and other natural disasters are not.
> 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. --- 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.
> 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.
Also -- BTW, you mentioned "xdm" -- suppose it was PAM compliant. Regardless, CAPP also requires that you specify what files are in the "TCB" -- which ones have had a security check. I wouldn't have xdm on my system unless it had gone through a security check to ensure it is compliant with my system security policy.
> 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.
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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