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:	Fri, 7 Sep 2007 11:34:08 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Satyam Sharma <satyam@...radead.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: NFS4 authentification / fsuid

On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
> Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
> but you get the gist....
> 
> The point is that it is easy to subvert userspace if you have enough
> privileges. In the above example it may not be entirely undetectable,
> but who here is running a script on every login to check that / is
> indeed uncompromised?

I suppose this is the motivation for things like the "secure attention
key"?

But I'm most curious actually about to what degree the kernel itself is
vulnerable to root (without a reboot).  Is disabling /dev/kmem and
module-loading in theory enough?  (Modulo bugs like filesystems that
aren't secure against untrusted filesystems, etc.)

--b.
-
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/