linux-kernel - Re: Pull request for FS-Cache, including NFS patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090101090900.551ada4a@infradead.org>
Date:	Thu, 1 Jan 2009 09:09:00 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	"Muntz, Daniel" <Dan.Muntz@...app.com>
Cc:	"Trond Myklebust" <trond.myklebust@....uio.no>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Stephen Rothwell" <sfr@...b.auug.org.au>,
	"Bernd Schubert" <bernd.schubert@...tmail.fm>,
	<nfsv4@...ux-nfs.org>, <linux-kernel@...r.kernel.org>,
	<steved@...hat.com>, <dhowells@...hat.com>,
	<linux-next@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
	<rwheeler@...hat.com>
Subject: Re: Pull request for FS-Cache, including NFS patches

On Wed, 31 Dec 2008 20:11:13 -0800
"Muntz, Daniel" <Dan.Muntz@...app.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/