[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Oct 2004 18:55:38 -0400
From: Steven Lembark <lembark@...hors.com>
To: owl-users@...ts.openwall.com
Subject: Re: sudo: why not?
> The root user could access the database files physically
> (binaryphorically speaking) and thus already has this privilege. There is
> really no such thing as security against the superuser.
My point was that there is no good definition of
"less privileged" user in the first place since
the notion of privilege is context sensitive.
i.e., even adding some sort of privilege-tree to
the what-user-can-change-to-what does not help.
Thing is that this is Unix, not VMS or OS/390.
At some point the entire thing comes down to
someone somewhere having personal control of
something.
> Apart from a single exploitable bug in a networking daemon running as
> root. Or a single exploitable bug in any non-chrooted networking daemon
> and a single (or series of, possibly) exploitable local bugs that leads
> to elevated privileges.
Execept for any bug that leads to any hole anywhere.
There will always be holes; the best you can ever do
is leave the system less likely to be cracked (as
you've already pointed out).
That doesn't mean I won't at least take the simpler
steps to avoid the more easily-avoidable pitfalls.
> The users you want to safeguard against are the ones that doesn't need
> just "simple" access to the command.
Such as?
> Would you care to elaborate? Are you assuming the position of an attacker
> or the position of an admin in that statement?
As an admin if someone's account has been compromised
I can disable it. Turning off the superuser account(s)
tends to be more problematic. Obviously there are
lingering issues of what might have been done to the
the system in the meantime.
> Rootkits needs root access to be installed. We're trying to prevent that
> altogether, not make sure we can find them once they're installed.
Trivial: patch out the tests for ! uid in the C source,
add a signal handler for graceful shutdown to the reset
button, and put someone with an uzi near the box.
> uid 1000 has three. Is that a real problem? ;)
Three uid == 0 ?
> Actually, not even that would be perfectly secure, but it would make it
> harder for anyone sitting there to go berzerk without being noticed.
> Again, we're not interested in noticing things when they've happened, but
> rather to prevent them.
Think hard about VMS. It died largely because NSA
designed too much of it, at which point the thing
became so unwieldy that people switched to *NIX in
response.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@...hors.com 1 888 359 3508
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
