NFS4 authentification / fsuid

NFS4 authentification / fsuid

[Jan Engelhardt]

Hi,


with NFS3, there is this 'root hole', i.e. any person who has a root 
account (perhaps by use of a laptop) can mount an export (let's say this 
export had the "root_squash" option), and still have a look at the user 
files, because he can locally setuid() into another user.

So I was looking for alternatives. CIFS is my favorite candidate, but it 
has a few issues right now. So does sshfs and about everything I have 
come across. Since I remember NFS4 can use KRB5 authentification, my 
question is, will the NFS(4) server process run with an fsuid equal to 
the user that authenticated?


thanks,
	Jan
-- 

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> Hi,
> 
> 
> with NFS3, there is this 'root hole', i.e. any person who has a root 
> account (perhaps by use of a laptop) can mount an export (let's say this 
> export had the "root_squash" option), and still have a look at the user 
> files, because he can locally setuid() into another user.
> 
> So I was looking for alternatives. CIFS is my favorite candidate, but it 
> has a few issues right now. So does sshfs and about everything I have 
> come across. Since I remember NFS4 can use KRB5 authentification, my 
> question is, will the NFS(4) server process run with an fsuid equal to 
> the user that authenticated?
> 
> 
> thanks,
> 	Jan

NFSv3 should work fine with krb5 too, but that won't solve your problem
with setuid: kerberos saves the TGT in a file on /tmp, so root can still
suid and grab your cred (and the same goes for CIFS).

We've got people working on fixing this problem using David Howells'
keyrings, but it will probably be a while until we've solved all the
upcall issues, and it will probably take even longer to push the
kerberos changes back to the official MIT etc distros.

Cheers
  Trond

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-08-30 at 10:29 -0400, Trond Myklebust wrote:
> We've got people working on fixing this problem using David Howells'
> keyrings, but it will probably be a while until we've solved all the
> upcall issues, and it will probably take even longer to push the
> kerberos changes back to the official MIT etc distros.

BTW: even when this task is done, a creative root can still find ways to
subvert the security (he can read /dev/mem, replace the kernel with a
compromised one, ....). The bottom line is that if you can't trust root,
don't even log in.

Trond

Re: NFS4 authentification / fsuid

[Jan Engelhardt]

On Aug 30 2007 10:29, Trond Myklebust wrote:
>On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
>> 
>> with NFS3, there is this 'root hole', i.e. any person who has a root 
>> account (perhaps by use of a laptop) can mount an export (let's say this 
>> export had the "root_squash" option), and still have a look at the user 
>> files, because he can locally setuid() into another user.
>> 
>> So I was looking for alternatives. CIFS is my favorite candidate, but it 
>> has a few issues right now. So does sshfs and about everything I have 
>> come across. Since I remember NFS4 can use KRB5 authentification, my 
>> question is, will the NFS(4) server process run with an fsuid equal to 
>> the user that authenticated?
>
>NFSv3 should work fine with krb5 too, but that won't solve your problem
>with setuid: kerberos saves the TGT in a file on /tmp, so root can still
>suid and grab your cred (and the same goes for CIFS).

Hm? I do not see this problem with CIFS. The user may have local
root, but on the server, he only has his non-root account on the
server, and as such, can only operate on the server using this
non-root fsuid. Did I miss something? (Especially the /dev/mem thing
is not quite clear to me.)

>BTW: even when this task is done, a creative root can still find ways to
>subvert the security (he can read /dev/mem, replace the kernel with a
>compromised one, ....). The bottom line is that if you can't trust root,
>don't even log in.


	Jan
-- 

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-08-30 at 16:42 +0200, Jan Engelhardt wrote:
> On Aug 30 2007 10:29, Trond Myklebust wrote:
> >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> >> 
> >> with NFS3, there is this 'root hole', i.e. any person who has a root 
> >> account (perhaps by use of a laptop) can mount an export (let's say this 
> >> export had the "root_squash" option), and still have a look at the user 
> >> files, because he can locally setuid() into another user.
> >> 
> >> So I was looking for alternatives. CIFS is my favorite candidate, but it 
> >> has a few issues right now. So does sshfs and about everything I have 
> >> come across. Since I remember NFS4 can use KRB5 authentification, my 
> >> question is, will the NFS(4) server process run with an fsuid equal to 
> >> the user that authenticated?
> >
> >NFSv3 should work fine with krb5 too, but that won't solve your problem
> >with setuid: kerberos saves the TGT in a file on /tmp, so root can still
> >suid and grab your cred (and the same goes for CIFS).
> 
> Hm? I do not see this problem with CIFS. The user may have local
> root, but on the server, he only has his non-root account on the
> server, and as such, can only operate on the server using this
> non-root fsuid.

With CIFS or other password based protocols (including RPCSEC_GSS) all
the root user needs in order to steal your identity is to grab a copy of
your password or a credential. It is not quite as trivial to do as
changing uid, but it is hardly rocket science if the compromised machine
is one that you log into regularly.

>  Did I miss something? (Especially the /dev/mem thing
> is not quite clear to me.)
> 
> >BTW: even when this task is done, a creative root can still find ways to
> >subvert the security (he can read /dev/mem, replace the kernel with a
> >compromised one, ....). The bottom line is that if you can't trust root,
> >don't even log in.

What I'm saying is that the superuser can pretty much do whatever it
takes to grab either your kerberos password (e.g. install a keyboard
listener), a stored credential (read the contents of your kerberos
on-disk credential cache), or s/he can access the cached contents of the
file by hunting through /dev/kmem.

IOW: There is no such thing as security on a root-compromised machine.

Trond

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> With CIFS or other password based protocols (including RPCSEC_GSS)

Well, rpcsec_gss isn't inherently password based, and you can
authenticate in some way that doesn't actually give away your password
(or other long-lived credential).

> What I'm saying is that the superuser can pretty much do whatever it
> takes to grab either your kerberos password (e.g. install a keyboard
> listener), a stored credential (read the contents of your kerberos
> on-disk credential cache), or s/he can access the cached contents of the
> file by hunting through /dev/kmem.
> 
> IOW: There is no such thing as security on a root-compromised machine.

And in theory a kernel could provide *some* guarantees against root,
right?  (Is there some reason a unix-like kernel must provide such
things as /dev/kmem?)

--b.

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Thu, 30 Aug 2007, J. Bruce Fields wrote:

> On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> > With CIFS or other password based protocols (including RPCSEC_GSS)
> 
> Well, rpcsec_gss isn't inherently password based, and you can
> authenticate in some way that doesn't actually give away your password
> (or other long-lived credential).
> 
> > What I'm saying is that the superuser can pretty much do whatever it
> > takes to grab either your kerberos password (e.g. install a keyboard
> > listener), a stored credential (read the contents of your kerberos
> > on-disk credential cache), or s/he can access the cached contents of the
> > file by hunting through /dev/kmem.
> > 
> > IOW: There is no such thing as security on a root-compromised machine.
> 
> And in theory a kernel could provide *some* guarantees against root,
> right?  (Is there some reason a unix-like kernel must provide such
> things as /dev/kmem?)

/dev/kmem was just an example -- IMHO differentiating between kernel and
userspace from a security p.o.v. is always tricky. Like Trond said, there
are very high number of ways in which privileged userspace can compromise
a running kernel if it really wants to do that, root-is-God has always
been *the* major problem with Unix :-)

The only _real_ way a kernel can lock itself completely against malicious
userspace involves trusted tamperproof hardware, but even that only if
you can get yourself to believe such a thing exists in the first place ;-)


Satyam

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Thu, 6 Sep 2007, Satyam Sharma wrote:
> 
> On Thu, 30 Aug 2007, J. Bruce Fields wrote:
> 
> > On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> > 
> > > What I'm saying is that the superuser can pretty much do whatever it
> > > takes to grab either your kerberos password (e.g. install a keyboard
> > > listener), a stored credential (read the contents of your kerberos
> > > on-disk credential cache), or s/he can access the cached contents of the
> > > file by hunting through /dev/kmem.
> > > 
> > > IOW: There is no such thing as security on a root-compromised machine.
> > 
> > And in theory a kernel could provide *some* guarantees against root,
> > right?  (Is there some reason a unix-like kernel must provide such
> > things as /dev/kmem?)
> 
> /dev/kmem was just an example -- IMHO differentiating between kernel and
> userspace from a security p.o.v. is always tricky. Like Trond said, there
> are very high number of ways in which privileged userspace can compromise
> a running kernel if it really wants to do that, root-is-God has always
    ^^^^^^^^^^^^^^

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


> been *the* major problem with Unix :-)
> 
> The only _real_ way a kernel can lock itself completely against malicious
> userspace involves trusted tamperproof hardware, but even that only if
> you can get yourself to believe such a thing exists in the first place ;-)

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

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.  Or people with root on a virtual host don't
necessarily have the ability to replace the kernel for that host.

--b.

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-09-06 at 11:11 -0400, 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.  Or people with root on a virtual host don't
> necessarily have the ability to replace the kernel for that host.

mount -t tmpfs none /my_tmpfs
cd /my_tmpfs
cp -a /bin bin
cp -p my_keylogging_pam_module.so lib
pivot_root . /old-root

to take another example....

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Fri, 2007-09-07 at 01:21 +0200, Trond Myklebust wrote:
> On Thu, 2007-09-06 at 11:11 -0400, 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.  Or people with root on a virtual host don't
> > necessarily have the ability to replace the kernel for that host.
> 
> mount -t tmpfs none /my_tmpfs
> cd /my_tmpfs
> cp -a /bin bin
> cp -p my_keylogging_pam_module.so lib
> pivot_root . /old-root

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?

Trond

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

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.

Re: NFS4 authentification / fsuid

[Satyam Sharma]

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).

Re: NFS4 authentification / fsuid

[Satyam Sharma]

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

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
> /dev/kmem was just an example -- IMHO differentiating between kernel and
> userspace from a security p.o.v. is always tricky.

The things that come to mind are /dev/kmem and module-loading.  What
else is there?  And what is it that makes this inherently difficult?

> Like Trond said, there are very high number of ways in which
> privileged userspace can compromise a running kernel if it really
> wants to do that, root-is-God has always been *the* major problem with
> Unix :-)
> 
> The only _real_ way a kernel can lock itself completely against
> malicious userspace involves trusted tamperproof hardware,

The question of how to protect against someone with *physical* access
certainly is more difficult, but surely that's a separate problem.

--b.

Re: NFS4 authentification / fsuid

[Kyle Moffett]

On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
>> Like Trond said, there are very high number of ways in which  
>> privileged userspace can compromise a running kernel if it really  
>> wants to do that, root-is-God has always been *the* major problem  
>> with Unix :-)
>>
>> The only _real_ way a kernel can lock itself completely against  
>> malicious userspace involves trusted tamperproof hardware,
>
> The question of how to protect against someone with *physical*  
> access certainly is more difficult, but surely that's a separate  
> problem.

Actually, that's a fairly simple problem (barring disassembling the  
system and attaching a hardware debugger).  You encrypt the root  
filesystem and require a password to boot (See: LUKS).  Debian has  
built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and  
it works quite well on all the laptops I use regularly.  It's not  
even much of a speed penalty; once you take the overhead of hitting a  
5400RPM laptop drive you can chew thousands of cycles of CPU without  
anybody noticing (much).  Then all you have to do is burn a copy of  
your /boot with bootloader onto some read-only media (like a  
finalized CDROM/DVDROM) and you're set to go.

Cheers,
Kyle Moffett

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
> >> Like Trond said, there are very high number of ways in which  
> >> privileged userspace can compromise a running kernel if it really  
> >> wants to do that, root-is-God has always been *the* major problem  
> >> with Unix :-)
> >>
> >> The only _real_ way a kernel can lock itself completely against  
> >> malicious userspace involves trusted tamperproof hardware,
> >
> > The question of how to protect against someone with *physical*  
> > access certainly is more difficult, but surely that's a separate  
> > problem.
> 
> Actually, that's a fairly simple problem (barring disassembling the  
> system and attaching a hardware debugger).  You encrypt the root  
> filesystem and require a password to boot (See: LUKS).  Debian has  
> built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and  
> it works quite well on all the laptops I use regularly.  It's not  
> even much of a speed penalty; once you take the overhead of hitting a  
> 5400RPM laptop drive you can chew thousands of cycles of CPU without  
> anybody noticing (much).  Then all you have to do is burn a copy of  
> your /boot with bootloader onto some read-only media (like a  
> finalized CDROM/DVDROM) and you're set to go.

Disconnect battery, and watch boot password go 'poof!'.

Trond

Re: NFS4 authentification / fsuid

[Kyle Moffett]

On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
>> Actually, that's a fairly simple problem (barring disassembling  
>> the system and attaching a hardware debugger).  You encrypt the  
>> root filesystem and require a password to boot (See: LUKS).   
>> Debian has built-in support for installing onto fs-on-LVM-on-crypt- 
>> on-RAID, and it works quite well on all the laptops I use  
>> regularly.  It's not even much of a speed penalty; once you take  
>> the overhead of hitting a 5400RPM laptop drive you can chew  
>> thousands of cycles of CPU without anybody noticing (much).  Then  
>> all you have to do is burn a copy of your /boot with bootloader  
>> onto some read-only media (like a finalized CDROM/DVDROM) and  
>> you're set to go.
>
> Disconnect battery, and watch boot password go 'poof!'.

Umm, I did say "encrypt the root filesystem", didn't I?  Booting my  
laptops this way follows this procedure:
   1) Enter BIOS boot menu
   2) Insert /boot CDROM
   3) Select the "CDROM" entry
   4) Wait for kernel to start and run through initramfs
   5) Type password into the initramfs prompt so that it can DECRYPT  
THE ROOT FILESYSTEM
   6) Continue to boot the system.

Under this setup, tinkering with my BIOS does virtually nothing; the  
only avenues of attack are strictly of the "Install a hardware  
keylogger" variety.  Without my "boot" password you are looking at a  
block device which appears to be little more than a random bit- 
bucket, using AES-256 encryption.  If you can break that by  
disconnecting the BIOS battery a lot of governments would be very  
interested in the exact procedure. :-D  Furthermore if I think that  
the hardware has been compromised I can pull out the HDD and my CDROM  
and take them to a trusted computer to gain access to my data.

That said, a useful BIOS password helps keep somebody from casually  
setting a supervisor password or mucking with the critical-to-boot  
settings and making _me_ unplug the battery.

Cheers,
Kyle Moffett

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> >> Actually, that's a fairly simple problem (barring disassembling  
> >> the system and attaching a hardware debugger).  You encrypt the  
> >> root filesystem and require a password to boot (See: LUKS).   
> >> Debian has built-in support for installing onto fs-on-LVM-on-crypt- 
> >> on-RAID, and it works quite well on all the laptops I use  
> >> regularly.  It's not even much of a speed penalty; once you take  
> >> the overhead of hitting a 5400RPM laptop drive you can chew  
> >> thousands of cycles of CPU without anybody noticing (much).  Then  
> >> all you have to do is burn a copy of your /boot with bootloader  
> >> onto some read-only media (like a finalized CDROM/DVDROM) and  
> >> you're set to go.
> >
> > Disconnect battery, and watch boot password go 'poof!'.
> 
> Umm, I did say "encrypt the root filesystem", didn't I?  Booting my  
> laptops this way follows this procedure:
>    1) Enter BIOS boot menu
>    2) Insert /boot CDROM
>    3) Select the "CDROM" entry
>    4) Wait for kernel to start and run through initramfs
>    5) Type password into the initramfs prompt so that it can DECRYPT  
> THE ROOT FILESYSTEM
>    6) Continue to boot the system.
> 
> Under this setup, tinkering with my BIOS does virtually nothing; the  
> only avenues of attack are strictly of the "Install a hardware  
> keylogger" variety.  Without my "boot" password you are looking at a  
> block device which appears to be little more than a random bit- 
> bucket, using AES-256 encryption.  If you can break that by  
> disconnecting the BIOS battery a lot of governments would be very  
> interested in the exact procedure. :-D  Furthermore if I think that  
> the hardware has been compromised I can pull out the HDD and my CDROM  
> and take them to a trusted computer to gain access to my data.
> 
> That said, a useful BIOS password helps keep somebody from casually  
> setting a supervisor password or mucking with the critical-to-boot  
> settings and making _me_ unplug the battery.
> 
> Cheers,
> Kyle Moffett

So an attacker will instead install a hardware keylogger, or swap out
your boot cdrom with a compromised but almost identical boot cdrom
instead, or mod your bios, ...

A fully self-certifying system that can prevent any attack is _very_
hard to achieve. Just ask apple (iPhone) or any games console vendor...

Trond

Re: NFS4 authentification / fsuid

[Kyle Moffett]

On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote:
> On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
>> Umm, I did say "encrypt the root filesystem", didn't I?  Booting  
>> my laptops this way follows this procedure:
>>    1) Enter BIOS boot menu
>>    2) Insert /boot CDROM
>>    3) Select the "CDROM" entry
>>    4) Wait for kernel to start and run through initramfs
>>    5) Type password into the initramfs prompt so that it can  
>> DECRYPT THE ROOT FILESYSTEM
>>    6) Continue to boot the system.
>>
>> [...] the only avenues of attack are strictly of the "Install a  
>> hardware keylogger" variety.
>
> So an attacker will instead install a hardware keylogger, or swap  
> out your boot cdrom with a compromised but almost identical boot  
> cdrom instead, or mod your bios, ...
>
> A fully self-certifying system that can prevent any attack is  
> _very_ hard to achieve. Just ask apple (iPhone) or any games  
> console vendor...

A fully self-certifying system that can prevent any attack is  
impossible to achieve.  If I have the device and can devote as many  
hours as I want to breaking into it, there is exactly ZERO way to  
prevent that, aside from encrypting things and not giving out the key  
(which sorta makes it useless but is precisely the point of real  
crypto).

There is a HUGE difference between "I don't want the end-user to hack  
into this" and "The end-user wants a certain degree of assurance that  
his data can't be compromised.  In the former case (IE: DRM) you are  
NOT using cryptography because you are giving the user: (A) the data,  
(B) the algorithm, and (C) the key, which means they can decrypt it  
ANY TIME THEY WANT.  In the latter case the attacker DOES NOT have  
the key and virtually all of the attacks forms of "How do I get the  
key?".  The end-user is REQUIRED to provide an appropriate level of  
physical security based on the nature of the data;  If I'm that  
worried about somebody substituting my /boot CD, then I'm going to  
make DAMN sure that I keep it on my person at all times.

So you can't draw any relationships between "Protect the end-user"  
with "Protect the device FROM the end-user", the former can be done  
very reliably to whatever level of risk-reduction you need and the  
latter can't practically be done at all.

Cheers,
Kyle Moffett

Re: NFS4 authentification / fsuid

[Bernd Eckenfels]

In article <3BBEDBBC-FD71-4A6F-81B3-EC0978A37024@mac.com> you wrote:
> So you can't draw any relationships between "Protect the end-user"  
> with "Protect the device FROM the end-user", the former can be done  
> very reliably to whatever level of risk-reduction you need and the  
> latter can't practically be done at all.

Unless you use a TPM Chip.

Gruss
Bernd

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Fri, 7 Sep 2007, Kyle Moffett wrote:
> 
> So you can't draw any relationships between "Protect the end-user" with
> "Protect the device FROM the end-user", the former can be done very reliably
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ *attacker*

> to whatever level of risk-reduction you need and the latter can't practically
> be done at all.

Well, you're the one who called solving the physical access problem
"easy" here ... :-)

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Thu, 6 Sep 2007, Kyle Moffett wrote:
> 
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> > 
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> > > 
> > > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > > > The question of how to protect against someone with *physical*
                                               ^^^^^^^^^^^^^^^^^^^^^^^
> > > > access certainly is more difficult, but surely that's a separate
        ^^^^^^

> > > > problem.
> > > 
> > > Actually, that's a fairly simple problem (barring disassembling the system
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > > and attaching a hardware debugger).  You encrypt the root filesystem and
> > > require a password to boot (See: LUKS).  Debian has built-in support for
> > > installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all
> > > the laptops I use regularly.  It's not even much of a speed penalty; once
> > > you take the overhead of hitting a 5400RPM laptop drive you can chew
> > > thousands of cycles of CPU without anybody noticing (much).  Then all you
> > > have to do is burn a copy of your /boot with bootloader onto some
> > > read-only media (like a finalized CDROM/DVDROM) and you're set to go.
> > 
> > Disconnect battery, and watch boot password go 'poof!'.
> 
> Umm, I did say "encrypt the root filesystem", didn't I?  Booting my laptops
                                                                      ^^^^^^^

The whole *point* here is to secure against physical access -- then how
can you assume "barring disassembling the system"? If you're not
considering attacks such as those, then how _are_ you solving the
physical access problem in the first place? :-)


> this way follows this procedure:
>  1) Enter BIOS boot menu
>  2) Insert /boot CDROM
>  3) Select the "CDROM" entry
>  4) Wait for kernel to start and run through initramfs
>  5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT
> FILESYSTEM
>  6) Continue to boot the system.
> 
> Under this setup, tinkering with my BIOS does virtually nothing; the only
> avenues of attack are strictly of the "Install a hardware keylogger" variety.

Doesn't flashing/replacing your BIOS firmware/chip count as tinkering?
Then I don't really need a "hardware keylogger", do I ...

Re: NFS4 authentification / fsuid

[Kyle Moffett]

On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
> On Thu, 6 Sep 2007, Kyle Moffett wrote:
>> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
>>> On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
>>>> On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
>>>>> The question of how to protect against someone with *physical*  
>>>>> access certainly is more difficult, but surely that's a  
>>>>> separate problem.
>>>>
>>>> Actually, that's a fairly simple problem (barring disassembling  
>>>> the system and attaching a hardware debugger).  You encrypt the  
>>>> root filesystem and  require a password to boot (See: LUKS).   
>>>> Debian has built-in support for installing onto fs-on-LVM-on- 
>>>> crypt-on-RAID, and it works quite well on all the laptops I use  
>>>> regularly.  It's not even much of a speed penalty; once you take  
>>>> the overhead of hitting a 5400RPM laptop drive you can chew  
>>>> thousands of cycles of CPU without anybody noticing (much).   
>>>> Then all you have to do is burn a copy of your /boot with  
>>>> bootloader onto some read-only media (like a finalized CDROM/ 
>>>> DVDROM) and you're set to go.
>>>
>>> Disconnect battery, and watch boot password go 'poof!'.
>>
>> Umm, I did say "encrypt the root filesystem", didn't I?  Booting  
>> my laptops
>
> The whole *point* here is to secure against physical access -- then  
> how can you assume "barring disassembling the system"? If you're  
> not considering attacks such as those, then how _are_ you solving  
> the physical access problem in the first place? :-)

Security is about fractional reduction of risk, and anybody who tells  
you otherwise is either ignorant or lying through their teeth.  There  
are *multiple* aspects of "physical access"; one of those is access  
while the box is off and no data resident in volatile memory, which  
is the easy case.  Basically there you can just encrypt the non- 
volatile storage.  If the system is *on* and has unencrypted data in  
memory (such as suspend-to-RAM for example) then you *HAVE* to ensure  
that it can't be easily disassembled and a hardware debugger  
attached; there is no way around that very fundamental limitation.

Basically if the key is resident and unencrypted as is necessary to  
*USE* the system, then no amount of hardware is going to *prevent* a  
dedicated attacker from getting at it unless you make it so  
unportable that you don't have to worry about somebody carrying it  
off in the first place.  Typical mechanisms to increase the time and  
effort to break into a device include wiring the entire enclosure  
with extremely thin filament wires and detecting automatically wiping  
the system upon any variation in a small flow of current through said  
filament.

>> this way follows this procedure:
>>  1) Enter BIOS boot menu
>>  2) Insert /boot CDROM
>>  3) Select the "CDROM" entry
>>  4) Wait for kernel to start and run through initramfs
>>  5) Type password into the initramfs prompt so that it can DECRYPT  
>> THE ROOT FILESYSTEM
>>  6) Continue to boot the system.
>>
>> Under this setup, tinkering with my BIOS does virtually nothing;  
>> the only avenues of attack are strictly of the "Install a hardware  
>> keylogger" variety.
>
> Doesn't flashing/replacing your BIOS firmware/chip count as  
> tinkering?  Then I don't really need a "hardware keylogger", do I ...

Ok, so you are saying your plan of attack on this system would be:
   1)  Steal the laptop such that I don't notice it has been stolen
   2)  Open it up
   3)  Replace the very-vendor-specific BIOS chip with a reflashed  
one with sufficient storage to do all the things the old BIOS could  
*AND* have enough storage for an entire replacement kernel binary  
with a built-in keylogger, as well as some storage for the logged  
password
   4)  Return the laptop, again such that I don't notice it has been  
missing
   5)  Wait for me to boot and type my password
   6)  Somehow recover the laptop *yet* *again* to get the password  
back off of it and decrypt the disk

Yes it "can be done", but so can dumping the firmware for an iPod out  
through the built-in piezo clicker[1].  USE SOME COMMON SENSE HERE  
PEOPLE!!!  The only "unbreakable" computer is one always disconnected  
and off under armed guard in a bank vault, and even then it's only as  
secure as the bank in which it is stored (which get broken into on  
occasion).

I am assuming that if the laptop has sufficiently important data on  
it to warrant the above steps then I am also clueful enough to:
   (A)  Not carry the laptop around unsecured areas,
   (B)  Keep a close enough eye on it and be aware that it's gone by  
the time they get to step 2, OR
   (C)  Pay somebody to build me a better physical chassis for my laptop

We are talking about *STANDARD* laptop systems with reasonably alert  
users.  If the user doesn't know how to properly protect the stuff on  
the laptop then they probably don't know how to properly protect the  
other copy in their heads, either.  Besides, if some government  
wanted the data on your laptop that bad they'd just pick you up in  
the middle of the night and torture your password out of you.

On Sep 18, 2007, at 19:48:16, Satyam Sharma wrote:
> On Fri, 7 Sep 2007, Kyle Moffett wrote:
>> So you can't draw any relationships between "Protect the end-user"  
>> with "Protect the device FROM the end-user", the former can be  
>> done very reliably to whatever level of risk-reduction you need  
>> and the latter can't practically be done at all.
>
> Well, you're the one who called solving the physical access problem  
> "easy" here ... :-)

If your system equates end-user with attacker then you are *screwed*  
regardless!  If you give the end-user the tools that they need to use  
the system, then they can just as easily hack into it, *END* *OF*  
*STORY*.  See   The _only_ way to protect data on a piece of hardware  
is with the _assistance_ of the end-user; they have to be alert and  
aware of potential threats and act to protect from them.

Cheers,
Kyle Moffett

[1] http://hardware.slashdot.org/article.pl?sid=05/01/29/2017244

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Wed, 19 Sep 2007, Kyle Moffett wrote:
> 
> On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
> > 
> > The whole *point* here is to secure against physical access -- then how can
                                                ^^^^^^^^^^^^^^^
> > you assume "barring disassembling the system"? If you're not considering
> > attacks such as those, then how _are_ you solving the physical access
> > problem in the first place? :-)
> 
> [snip lots of totally irrelevant stuff]

???

What is your point, really?

Let me repeat the situation:

I own a computer (maybe portable one, such as a laptop) that I want to
protect from attackers with physical access to my system. You're proposing
a scheme that claims to secure it (against attackers with physical access)
but assumes: "barring disassembling the system".

Dude, looks like you're selling snake oil here.


> > > Under this setup, tinkering with my BIOS does virtually nothing; the only
> > > avenues of attack are strictly of the "Install a hardware keylogger"
> > > variety.
> > 
> > Doesn't flashing/replacing your BIOS firmware/chip count as tinkering?  Then
> > I don't really need a "hardware keylogger", do I ...
> 
> Ok, so you are saying your plan of attack on this system would be:
>  1)  Steal the laptop such that I don't notice it has been stolen
>  2)  Open it up
>  3)  Replace the very-vendor-specific BIOS chip with a reflashed one with
> sufficient storage to do all the things the old BIOS could *AND* have enough
> storage for an entire replacement kernel binary with a built-in keylogger, as
> well as some storage for the logged password
>  4)  Return the laptop, again such that I don't notice it has been missing
>  5)  Wait for me to boot and type my password
>  6)  Somehow recover the laptop *yet* *again* to get the password back off of
> it and decrypt the disk

Precisely. Do you think the above attack is "fantastical"?

Wow, you're amazingly naive ... good luck ;-)

[ See, if it's only your kid sister that you want to "protect" your
  36GB worth of porn from, then you might as well use Windoze and one of
  those cute little "folder-locking" tool that we wrote back in 5th grade.

  However, if "hapless North Korean spy in Washington" describes you more
  accurately, then you better be ready for all sorts of attacks -- from
  exploding cigars [1], to poisoned ballpoint pens [2] :-)

  In short, you have no clue what you're talking about, and thankfully
  I'm not using any security software you had any part in designing :-) ]


> Yes it "can be done", but so can dumping the firmware for an iPod out through
> the built-in piezo clicker[1].  USE SOME COMMON SENSE HERE PEOPLE!!!  The only
> "unbreakable" computer is one always disconnected and off under armed guard in
> a bank vault, and even then it's only as secure as the bank in which it is
> stored (which get broken into on occasion).

Thanks for repeatedly making *my* point :-)

_You_ are the one who claimed protecting systems from attackers with
physical access to be a "fairly simple" problem ... and here you're
mentioning how *difficult* it is ...


> I am assuming that if the laptop has sufficiently important data on it to
> warrant the above steps then I am also clueful enough to:
>  (A)  Not carry the laptop around unsecured areas,

You might carry it home, might you not? What if your lover/girlfriend/wife
is one of them? [3]


>  (B)  Keep a close enough eye on it and be aware that it's gone by the time
> they get to step 2, OR

Hmm, you'd need to be a mutant to keep "close enough eyes" on your stuff
while you're sleeping ... or drugged (?)


>  (C)  Pay somebody to build me a better physical chassis for my laptop

ROTFL ... these "workarounds" above are even more hilarious than your
earlier "fairly simple" claim.


> We are talking about *STANDARD* laptop systems with reasonably alert users.
> If the user doesn't know how to properly protect the stuff on the laptop then
> they probably don't know how to properly protect the other copy in their
> heads, either.

Dude, if the data in there is really that important, then better not
store it on a computer / disk at all :-)


> Besides, if some government wanted the data on your laptop
> that bad they'd just pick you up in the middle of the night and torture your
> password out of you.

Surprisingly, you have (somewhat of) a point (!)


> On Sep 18, 2007, at 19:48:16, Satyam Sharma wrote:
> > On Fri, 7 Sep 2007, Kyle Moffett wrote:
> > > So you can't draw any relationships between "Protect the end-user" with
> > > "Protect the device FROM the end-user", the former can be done very
> > > reliably to whatever level of risk-reduction you need and the latter can't
> > > practically be done at all.
> > 
> > Well, you're the one who called solving the physical access problem "easy"
> > here ... :-)
> 
> If your system equates end-user with attacker
  ^^

"If"? Was there ever any doubt?

Heh, did you even read the thread you just replied to?

We're talking of consoles / hardware sold by commercial companies to
users here, where they want explicitly want to prevent the users from
being able to hack it. So yes, end user == attacker.

> then you are *screwed* regardless!

Ah, finally you make my point again for me :-)


Thanks for the laughs,

Satyam


[1] }
[2] } All real "attacks". History pop quiz: on whom? ;-)
[3] }

Re: NFS4 authentification / fsuid

[Kyle Moffett]

On Sep 19, 2007, at 08:16:30, Satyam Sharma wrote:
> [all sorts of crap about spies in washington needing stronger  
> protection than your average consumer]

Well no duh.  I think most of the 4-year-olds I know could have told  
you that.  What sense does it make to give a spy all sorts of fancy  
electronic listening and monitoring equipment and then rely on the  
physical security of your average Dell?  You _can_ make a laptop  
sufficiently secure that its data is encrypted and it cannot be  
physically compromised to install a hardware keylogger without  
virtually destroying the enclosure, but that's completely unnecessary  
for 99.99999% of the users on the planet.

We would be much better off if all the companies getting their data  
stolen out from under them on company laptops would just use basic  
drive encryption and implement basic physical-security training.   
*THAT* is where protecting the laptop is easy; all the bullcrap about  
foreign intelligence is just drawing focus off of how easy it is to  
achieve *adequate* physical protection where it matters.

 From a practical standpoint, an identity thief trying to determine  
which company to attack will just steal a few laptops from a company  
which doesn't encrypt them instead of going through all the very  
risky steps of trying to break into the laptops of one that does.

Of course, this also relies on being able to teach the stupid lusers  
with the laptops not to give their boot password to the "service tech  
on the phone"


>> If your system equates end-user with attacker
>
> "If"? Was there ever any doubt?
>
> Heh, did you even read the thread you just replied to?

Yes I did and I wanted to make it *really* clear that with average  
hardware you can properly protect against virtually all of the  
*common* attack vectors.  The pretty standard problems of "somebody  
stole the company laptop with a bunch of credit-card info on it" or  
"my personal financial data was on the laptop I left in the airport",  
are pretty easy to make safe.  Furthermore, that is *EXACTLY* the  
initial example I gave (my laptop with my personal data on it).


On the other hand, I made this point in my original email, so if this  
is what you were arguing about you've been preaching to the choir.

> We're talking of consoles / hardware sold by commercial companies  
> to  users here, where they want explicitly want to prevent the  
> users from  being able to hack it. So yes, end user == attacker.
>
>> then you are *screwed* regardless!
>
> Ah, finally you make my point again for me :-)


To quote myself again:
> A fully self-certifying system that can prevent any attack is  
> impossible to achieve.  If I have the device and can devote as many  
> hours as I want to breaking into it, there is exactly ZERO way to  
> prevent that, aside from encrypting things and not giving out the  
> key (which sorta makes it useless but is precisely the point of  
> real crypto).
>
> There is a HUGE difference between "I don't want the end-user to  
> hack into this" and "The end-user wants a certain degree of  
> assurance that his data can't be compromised.


Cheers,
Kyle Moffett

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Wed, 19 Sep 2007, Kyle Moffett wrote:
> 
> > [all sorts of crap about spies in washington needing stronger protection
> > than your average consumer]
> 
> [snip]
> 
> [...] all the bullcrap about foreign intelligence

Hehe, again, *you* started all the "bullcrap" about foreign "governments"
in the first place :-)


> is just drawing
> focus off of how easy it is to achieve *adequate* physical protection where it
                                          ^^^^^^^^
> matters.

Ah, so you're qualifying the discussion with the nice and subjective
"adequate" ... (you're still wrong, of course)


> Of course, this also relies on being able to teach the stupid lusers with the
> laptops not to give their boot password to the "service tech on the phone"

Let's stick on-topic here ... remember "securing a system against attacker
with physical access is fairly simple" ?

[ Took the liberty of removing some irrelevant digressions -- didn't see
  any solid security scheme that fulfils/justifies your earlier claim over
  there. ]


> > > If your system equates end-user with attacker
> > 
> > "If"? Was there ever any doubt?
> > 
> > Heh, did you even read the thread you just replied to?
> 
> Yes I did [...]

No, you didn't -- it was obvious from your reply :-)

> and I wanted to make it *really* clear that with average hardware
> you can properly protect against virtually all of the *common* attack vectors.
                                                         ^^^^^^

But what gave you the impression we're interested in discussing "common"
or "adequate enough" attack vectors here?

See, if you have something useful/new to contribute to the discussion,
that we don't already know, then please don't hold back and feel free to
do so ...


Satyam

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

On Wed, Sep 19, 2007 at 07:42:20PM +0530, Satyam Sharma wrote:
> 
> 
> On Wed, 19 Sep 2007, Kyle Moffett wrote:
> > 
> > > [all sorts of crap about spies in washington needing stronger protection
> > > than your average consumer]
> > 
> > [snip]
> > 
> > [...] all the bullcrap about foreign intelligence
> 
> Hehe, again, *you* started all the "bullcrap" about foreign "governments"
> in the first place :-)

Uh, is there somebody else that feels they're being enlightened by this
discussion?

--b.

Re: NFS4 authentification / fsuid

[Satyam Sharma]

On Wed, 19 Sep 2007, J. Bruce Fields wrote:
> 
> Uh, is there somebody else that feels they're being enlightened by this
> discussion?

Ok, probably I got a bit too harsh with Kyle there. But what I don't
understand is why is it so hard for someone to accept they're wrong
on this list, thank the other person and just move on ?!

Even when you've explained an attack that wasn't considered, you've
explained why the assumptions of the scheme were wrong, you've mentioned
previous precedents, and *technically* refuted the other person's claims.
Still, people feel obliged to *stick* to their (wrong) positions, subtly
"shift" their argument (using new adjectives or qualifiers), whatever,
just as long as they don't have to accept they were, simply, wrong.

That just sucks.

Re: NFS4 authentification / fsuid

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:

> I am assuming that if the laptop has sufficiently important data on  
> it to warrant the above steps then I am also clueful enough to:
>    (A)  Not carry the laptop around unsecured areas,
>    (B)  Keep a close enough eye on it and be aware that it's gone by  
> the time they get to step 2, OR
>    (C)  Pay somebody to build me a better physical chassis for my laptop

Building a better chassis can be a challenge when the threat model really
*does* include attacks by a well-funded TLA.

http://www.epic.org/crypto/scarfo/murch_aff.pdf

The FBI did an *initial* entry to survey the hardware, and then a total of
*five* other entries before they actually installed it.  Note the technical
and legal requirements required on the KLS (it had to, among other things,
capture PGP passphrases but *not* anything that was typed online).

>                                       Besides, if some government  
> wanted the data on your laptop that bad they'd just pick you up in  
> the middle of the night and torture your password out of you.

See above.  Though I *will* note that several years ago, a Department
of Justice filing regarding the use of wiretaps and similar tools reported
that in every single case that the FBI encountered encryption, it in fact
didn't stop the FBI from getting the info it was looking for.  Presumably,
they either used Scarfo-type devices, or they rolled somebody for the key.

They never *did* break Anthony Pellicano's PGP key, as far as I know....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: NFS4 authentification / fsuid

[Satyam Sharma]

Hi Valdis,


On Wed, 19 Sep 2007, Valdis.Kletnieks@vt.edu wrote:
> 
> On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:
> 
> > I am assuming that if the laptop has sufficiently important data on  
> > it to warrant the above steps then I am also clueful enough to:
> >    (A)  Not carry the laptop around unsecured areas,
> >    (B)  Keep a close enough eye on it and be aware that it's gone by  
> > the time they get to step 2, OR
> >    (C)  Pay somebody to build me a better physical chassis for my laptop
> 
> Building a better chassis can be a challenge when the threat model really
> *does* include attacks by a well-funded TLA.
> 
> http://www.epic.org/crypto/scarfo/murch_aff.pdf

Thanks for the link! And this was ... 1999 (!) Probably goes without
saying that physical hacking tricks have only become even more refined/
perfected by now :-)


> The FBI did an *initial* entry to survey the hardware, and then a total of
> *five* other entries before they actually installed it.  Note the technical
> and legal requirements required on the KLS (it had to, among other things,
> capture PGP passphrases but *not* anything that was typed online).


Thanks,

Satyam

Re: NFS4 authentification / fsuid

[J. Bruce Fields]

On Thu, Aug 30, 2007 at 04:42:33PM +0200, Jan Engelhardt wrote:
> 
> On Aug 30 2007 10:29, Trond Myklebust wrote:
> >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> >> 
> >> with NFS3, there is this 'root hole', i.e. any person who has a root 
> >> account (perhaps by use of a laptop) can mount an export (let's say this 
> >> export had the "root_squash" option), and still have a look at the user 
> >> files, because he can locally setuid() into another user.
> >> 
> >> So I was looking for alternatives. CIFS is my favorite candidate, but it 
> >> has a few issues right now. So does sshfs and about everything I have 
> >> come across. Since I remember NFS4 can use KRB5 authentification, my 
> >> question is, will the NFS(4) server process run with an fsuid equal to 
> >> the user that authenticated?
> >
> >NFSv3 should work fine with krb5 too, but that won't solve your problem
> >with setuid: kerberos saves the TGT in a file on /tmp, so root can still
> >suid and grab your cred (and the same goes for CIFS).
> 
> Hm? I do not see this problem with CIFS. The user may have local
> root, but on the server, he only has his non-root account on the
> server, and as such, can only operate on the server using this
> non-root fsuid. Did I miss something? (Especially the /dev/mem thing
> is not quite clear to me.)

The server will run with an fsuid equal to the user that authenticated,
you're correct.  So if you require krb5 access on an export, then nfs
access to a file on the export should be permitted only on rpc's that
are authenticated using credentials of a user with permission to access
the file.

Trond's pointing out that when you give the client your krb5 credentials
you're trusting it to do only what you tell it to with them.  You have
to trust the client's kernel at the very least, and also root on that
client, for the forseeable future.

--b.