linux-kernel - Re: NFS4 authentification / fsuid

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]

Date:	Wed, 19 Sep 2007 04:42:59 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	"J. Bruce Fields" <bfields@...ldses.org>
cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: NFS4 authentification / fsuid

On Thu, 6 Sep 2007, J. Bruce Fields wrote:
> 
> On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > Oh and btw, note that we're talking of the (lack of) security of a
> > "running kernel" here -- because across reboots, there is /really/
> > *absolutely* no such thing as "kernelspace security" because the superuser
> > will simply switch the vmlinuz itself ...
> 
> Well, the machine could be booting from cdrom, and could live in a
> locked machine room.

And how is this different from the "trusted tamperproof hardware"
solution I proposed earlier? From an attack vector p.o.v. they are both
precisely the same -- both of them are designed to prevent the attacker
from gaining unfettered access to system hardware, hmm?

Oh, actually, if past history is anything to go by, then your scheme
is provably weaker. Security systems are invariably always broken at
their weakest link, which is invariably always the human/social element,
and your scheme derives its security by relying on *social* element.

To elaborate my point, what prevents me from bribing / torturing /
blackmailing whoever owns the key to that locked server room and ...

The attack is "non-technical", but hey, so was your security :-)

> Or people with root on a virtual host don't
> necessarily have the ability to replace the kernel for that host.

Again, you're restricting physical access ... but okay, this is a slightly
more plausible solution (but one that applies to only a *specific* kind of
situation).

Satyam
-
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/