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).
Multiple persons per userid? Maybe in a casual environment, but
not on a security-conscious system. The whole point of a secure,
auditable OS is to tie responsibility for each action to a
particular person.
In a fixed purpose high-security system, you don't want general
purpose shell logins for all users. You don't want users running
setuid programs willy-nilly. A bank teller is *not* gonna suspend
the wire transfer app to type up a letter in emacs. The bank
computer isn't gonna be running sendmail (let alone procmail on
behalf of users). The receptionist isn't gonna be running a cron
job at 3:00 am to sort his pr0n.
> 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 !
Suppose B walks away from a logged in terminal, and Dr. Evil uses the
opportunity to make a setuid-B binary. Later on, Dr. Evil logs on as
himself, and then uses the setuid-B binary to print his own thesis,
charging it to B. User B then complains to the sysadmin "I didn't
print that, and I'm not gonna pay for it!" If the printer
accounting daemon had logged the luid, it would be trivial to
go hit Dr. Evil with a clue stick. Without it, you'd be stuck with
the fallible Unix real ID.
In the general case, B might not even correspond to a real person.
"B walking away from terminal" might be an exploit of a system
daemon, and "Dr. Evil" might be a disgruntled bank employee trying
to ruin the boss' career. There are also many systems (e.g.,
purchasing departments), where limited authority is delegated, but
actions must always be traceable to particular login events (and thus
to the responsible user). And most complex systems have lurking
vulnerabilities that allow back doors to be installed.
Ton Hospel's proposal:
> 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.
As far as I can tell, this is functionally similar to the luid/
session id proposal. But it has drawbacks:
1. *Lots* of logging (very slow, takes lots of storage)
2. Needs complicated, slow log analysis tools
3. Lossage intolerant (if chunk of log disappears, difficult
to interpret subsequent logging at all)
> This is MUCH more useful since it does not make the silly assumption that
> you should associate the login with who does something
That assumption is essential for holding a person responsible for their
actions. This doesn't matter for casual office use, but for financial
and military use it is essential. On an office system, you can just send
the relevant luser a flame. On a military system, someone will be held
person, and you'd better be damn sure who was logged in. (And the
military system wouldn't even have been procured in the first place
if it didn't meet the auditing requirements.)
[W.r.t Ton's proposal]
> 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 ?).
If luid auditing is important to you, then you're responsible for
reviewing every executable on the system. Nobody said secure systems
were easy or cheap to create.
> 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.
I disagree. Luid/session id is not a misguided retrofit, but a way to
leverage Unix for high-risk environments (high-risk meaning a problem
costs lots of money and maybe somebody goes to jail). Luid/sess_id is
pretty simple to implement, too. Two integers per process, a check to
tell when a login program is starting a user's shell, and a couple of
syscalls to get/set the integers. The only policy is "only login can
set luid" -- other policy is in userland.
----On an related note, I haven't noticed anything about including luid in the Unix domain socket credentials passing (maybe I just didn't see it). Is it planned? Would there be any point?
-- Daniel Newby
- 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