sudo and autofs

sudo and autofs

[chris barry]

Hey everyone. This is a little off topic, but I figured some here have
solved this already.

lab machine automounts users home from production environment.
user needs to use sudo to install a file on the local lab box that is in
his automounted home. 
result: permission denied. 

Makes sense, as root_squash is the default mount option. 

The question is, is there any way to make this work while preventing a
user from accessing another user's home? Some slick program type
automount map or something? anything...?


Thanks,
-C

Re: sudo and autofs

[Guillaume Rousse]

chris barry a écrit :
> The question is, is there any way to make this work while preventing a
> user from accessing another user's home? Some slick program type
> automount map or something? anything...?
ugly workaround: have users copy the file in the local /tmp directory
first, before accessing it with sudo second.

Otherwise, you may have a look at kerberized nfs for a much better
security, but that's not something easy to install.
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

Re: sudo and autofs

[Jim Carter]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1207 bytes --]

On Fri, 21 Mar 2008, Guillaume Rousse wrote:
> chris barry a écrit :
> > The question is, is there any way to make this work while preventing a
> > user from accessing another user's home? Some slick program type
> > automount map or something? anything...?
> ugly workaround: have users copy the file in the local /tmp directory
> first, before accessing it with sudo second.
> 
> Otherwise, you may have a look at kerberized nfs for a much better
> security, but that's not something easy to install.

I have a brief writeup on NFSv4: 
http://www.math.ucla.edu/~jimc/documents/nfsv4-0601.html

Unfortunately Kerberos is used to authenticate the client *host*, so 
hostbased impersonation schemes (rogue laptops) no longer work, but it 
still relies on the client to honestly report the alphabetic loginID and 
group ID of the client user, and so is vulnerable to a generic root exploit 
on the client.  

I show an autofs map row that mounts NFSv4, at the end.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 520 Portola Plaza; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: sudo and autofs

[Paul B. Henson]

On Fri, 21 Mar 2008, Jim Carter wrote:

> Unfortunately Kerberos is used to authenticate the client *host*, so
> hostbased impersonation schemes (rogue laptops) no longer work, but it
> still relies on the client to honestly report the alphabetic loginID and
> group ID of the client user, and so is vulnerable to a generic root
> exploit on the client.

I don't believe that to be the case -- Kerberos NFS authenticates the
end-users. If you're actually using Kerberos security, any access from a
local user without appropriate credentials is mapped to the nobody account
(or simply denied, I don't recall which)


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

Re: sudo and autofs

[Jim Carter]

On Mon, 24 Mar 2008, Paul B. Henson wrote:

> On Fri, 21 Mar 2008, Jim Carter wrote:
> 
> > Unfortunately Kerberos is used to authenticate the client *host*, so
> > hostbased impersonation schemes (rogue laptops) no longer work, but it
> > still relies on the client to honestly report the alphabetic loginID and
> > group ID of the client user, and so is vulnerable to a generic root
> > exploit on the client.
> 
> I don't believe that to be the case -- Kerberos NFS authenticates the
> end-users. If you're actually using Kerberos security, any access from a
> local user without appropriate credentials is mapped to the nobody account
> (or simply denied, I don't recall which)

I had hoped to test this by mounting something using -o sec=krb5 (as root 
with no TGT), accessing the content (as myself with a TGT), and then 
destroying my TGT and seeing what happened.  But after a recent OS upgrade, 
my NFSv4 test setup has become broken and I've run out of time for fixing 
it.  I'll continue working on this.

OK, I have a definitive answer: you're right.  Here's the URL:
http://www.citi.umich.edu/projects/nfsv4/gssd/
The user does something (like read()) requiring a GSS security context. 
The client's kernel has a cache of such contexts and representative tokens.
The token for (user x server) is missing, so it sends a message to rpc.gssd
    on the client to get one.
rpc.gssd infers the filename of the user's credential cache from the UID,
    chatters with the server's nfsd and rpc.svcgssd, and gets a security
    context (you hope).  
The client's kernel can now present a valid token to make the access 
    happen.

When the operation is done by root, like mounting, it's a special case and
the key needed to get the service ticket is found in the default 
keytab, rather than the usual way through the TGT.  

There are complaints that rpc.gssd only looks for /tmp/krb5cc_${UID} 
whereas pam_krb5 uses /tmp/krb5cc__{UID}_XXXXXX (randomized by mktemp).
There is supposed to be a patch for this but I haven't discovered yet 
whether I have it.

Access will not happen unless the KDC has nfs/${fqdn}@REALM for both hosts 
(can't mount) and for the user (can't create security context for 
read/write).

I still want to actually see it work/fail on my test machines.  But 
destroying my ticket will have no effect because the kernel caches it.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: sudo and autofs

[Paul B. Henson]

On Mon, 24 Mar 2008, Jim Carter wrote:

> There are complaints that rpc.gssd only looks for /tmp/krb5cc_${UID}
> whereas pam_krb5 uses /tmp/krb5cc__{UID}_XXXXXX (randomized by mktemp).
> There is supposed to be a patch for this but I haven't discovered yet
> whether I have it.

Even Red Hat 4 appears to have an rpc.gssd that does a more extensive
search for credentials, presumably any reasonably modern distribution will
as well.

> Access will not happen unless the KDC has nfs/${fqdn}@REALM for both hosts
> (can't mount) and for the user (can't create security context for
> read/write).

With newer versions of rpc.gssd you can tell it to use supplied credentials
rather than machine credentials for the mount and for root access. This
allows you to use secure NFS from a client on which you cannot obtain a
host principal. It's not particularly convenient though...



-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

Re: sudo and autofs

[christopher barry]

On Tue, 2008-03-25 at 12:51 -0800, Paul B. Henson wrote:
> On Mon, 24 Mar 2008, Jim Carter wrote:
> 
> > There are complaints that rpc.gssd only looks for /tmp/krb5cc_${UID}
> > whereas pam_krb5 uses /tmp/krb5cc__{UID}_XXXXXX (randomized by mktemp).
> > There is supposed to be a patch for this but I haven't discovered yet
> > whether I have it.
> 
> Even Red Hat 4 appears to have an rpc.gssd that does a more extensive
> search for credentials, presumably any reasonably modern distribution will
> as well.
> 
> > Access will not happen unless the KDC has nfs/${fqdn}@REALM for both hosts
> > (can't mount) and for the user (can't create security context for
> > read/write).
> 
> With newer versions of rpc.gssd you can tell it to use supplied credentials
> rather than machine credentials for the mount and for root access. This
> allows you to use secure NFS from a client on which you cannot obtain a
> host principal. It's not particularly convenient though...

Are both of you implying that with kerberized nfs, the local root user
can access a regular users nfs automounted home mounted with
-oroot_squash? Eg. Is this the answer I was looking for at the top of
this thread?

Regards,
-C