On Wed, 31 Dec 2008 20:11:13 -0800
"Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> wrote:
please don't top post.
> Sure, trusted kernel and trusted executables, but it's easier than it
> sounds. If you start with a "clean" system, you don't need to verify
> excutables _if_ they're coming from the secured file server (by
> induction: if you started out secure, the executables on the file
> server will remain secure). You simply can't trust the local disk
> from one user to the next. Following the protocol, a student can log
> into a machine, su to do their OS homework, but not compromise the
> security of the distributed file system.
>
> If I can su while another user is logged in, or the kernel/cmds are
> not validated between users, cryptfs isn't safe either.
>
> If you're following the protocol, it doesn't even matter if a bad guy
> ("untrusted user"?) gets root on the client--they still can't gain
> inappropriate access to the file server. OTOH, if my security plan is
> simply to not allow root access to untrusted users, history says I'm
> going to lose.
if you have a user, history says you're going to lose.
you can make your system as secure as you want, with physical access
all bets are off.
keyboard sniffer.. easy.
special dimms that mirror data... not even all THAT hard, just takes a
bit of cash.
running the user in a VM without him noticing.. not too hard either.
etc.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
