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]

Message-ID: <alpine.LFD.0.999.0709190443240.26241@enigma.security.iitk.ac.in>
Date:	Wed, 19 Sep 2007 04:57:30 +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 Fri, 7 Sep 2007, J. Bruce Fields wrote:
> 
> 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?

No, not in theory, not in practice. But yeah, restricting an attacker's
ability to hack hardware (by controlling physical access) does take out a
whole class of attack vectors.

But, seriously, such discussion has the tendency to quickly get toooo
theoretical (thus losing practical significance). For example, would we
not also need to prevent the (userspace) superuser from being able to run
arbitrary executables that can modify firmware? Okay, let's say we have
a kernelspace infrastructure of verifying cryptographic signatures on
binaries before executing them ... but how practical/usable is this?
How practically/universally applicable is a system whose security derives
from keeping machines behind locked doors and protected by incorruptible,
armed guard?

Overall, I tend to be unenthusiastic about most schemes that claim to
have solved the user-kernel security problem (with no loss of usability/
practicality).
-
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/