Mailing List Archive

--g7RHwRP26985.1030471107/dangermouse--

On Tue, Aug 27, 2002 at 10:25:08AM -0700, Allen, Pat wrote:
> Hi all,
>
> I hope that this isn't too obvious a question but here goes....
>
> I'm wondering how people are handling NFS security in environments
> where you have a lot of Mac OS X or Linux computer systems. For
> ease of administration, I would love to be able to specify that any
> computer within our network has read access to various qtrees. But
> this opens up a can of worms in that anybody with root access on
> their local Mac or Linux box can spoof user accounts with legitimate
> UID's and GID's. This essentially gives away the keys to the
> kingdom.

Don't export with root privs at all then.

> The other obvious alternative is using netgroups but that would be a
> lot of administration as machines come and go. It's certainly better
> than opening up access to everybody but not a course that I'd like
> to take.

Force them to use authenticatin and export via CIFS or something
instead.

> Are there any other alternatives that I'm missing? Thanks!

As I said, turn off the root to root mapping, only export items read
only that they need, anything else should be via authenticated login,
which CIFS supports and both Linux and OS X can do.

--
Mike Horwath Admin & Manager @ VISI.com WORK: drechsau@visi.com
IRC: Drechsau http://www.visi.com/ HOME: drechsau@geeks.org
The only Minnesota ISP with public statistics: http://noc.visi.com/
Garbage In -- Gospel Out. - berkeley fortune(6)

--g7RISpo22532.1030472931/dangermouse--

--g7RImWH22651.1030474112/dangermouse--

NFS is really annoying when you have to deploy it in a lab
environment. The best solution I've seen is the approach used
at http://tux.anu.edu.au/Projects/NFS_filter/. It does change the
networking setup of your typical lab. You basically put all of your
machines behind a linux router that authenticates and filters every nfs
request. The major downside is that this project doesn't seem to have
released any code, although they state their intention to do so. Another
solution which is not as comprehensive is the "secure export system" at
ftp://ftp.monash.edu.au/pub/keithl/SES/.

We've done something whereby the machine at boot contacts a
daemon running elsewhere. Using a shared secret the machine notifies the
daemon to modify the netgroup on the fly, allowing it to perform the
mount. It's still lousy, but it's not quite as bad as a raw export.

If you go the cifs route on Linux, you may want to update your smbfs
module to take advantage of cifs extensions for unix (see
http://uranus.it.swin.edu.au/~jn/linux/smbfs/) -- otherwise you'll get
errors when xauth attempts to lock the .Xauthority. The webpage also
describes a method of performing the smbmount automatically at login.
I recommend taking a look at pam_mount (http://www.flyn.org/) as an
alternate method of doing this.

I'm hoping NFSv4 can help in the future, but the linux patches are still
immature. Also the DataONTAP 6.2 docs say a Win2k KDC is required.



On Tue, 27 Aug 2002, Steve Losen wrote:

>
> > Hi all,
> >
> > I hope that this isn't too obvious a question but here goes....
> >
> > I'm wondering how people are handling NFS security in environments where you have a lot of Mac OS X or Linux computer systems. For ease of administration, I would love to be able to specify that any computer within our network has read access to various qtrees. But this opens up a can of worms in that anybody with root access on their local Mac or Linux box can spoof user accounts with legitimate UID's and GID's. This essentially gives away the keys to the kingdom.
> >
> > The other obvious alternative is using netgroups but that would be a lot of administration as machines come and go. It's certainly better than opening up access to everybody but not a course that I'd like to take.
>
> Both MacOS X and Linux have support for smb (cifs) filesystems, so
> you could use CIFS instead. It doesn't dovetail with unix as nicely
> as NFS, but it may be good enough.
>
> Steve Losen scl@virginia.edu phone: 434-924-0640
>
> University of Virginia ITC Unix Support
>
>
>

--g7RLNem24202.1030483421/dangermouse--

--g7RImWH22651.1030474112/dangermouse--

Kevin Noll
tel +44 7801765042
Cap Gemini Ernst & Young




-----Original Message-----
From: Steve Losen [mailto:scl@sasha.acc.virginia.edu]
Sent: 27 August 2002 19:06
To: Allen, Pat
Cc: Toasters (E-mail)
Subject: Re: NFS security concerns


--g7RImWH22651.1030474112/dangermouse--



********************************************************************************************
" This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only for
the person to whom it is addressed. If you are not the intended recipient, you
are not authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message ".
********************************************************************************************

whats this

-----Original Message-----
From: Steve Losen [mailto:scl@sasha.acc.virginia.edu]
Sent: Tuesday, August 27, 2002 11:36 PM
To: Allen, Pat
Cc: Toasters (E-mail)
Subject: Re: NFS security concerns


--g7RImWH22651.1030474112/dangermouse--

What is this g7RImWH22651 thing?

Kevin Noll
tel +44 7801765042
Cap Gemini Ernst & Young




-----Original Message-----
From: Steve Losen [mailto:scl@sasha.acc.virginia.edu]
Sent: 27 August 2002 19:06
To: Allen, Pat
Cc: Toasters (E-mail)
Subject: Re: NFS security concerns


--g7RImWH22651.1030474112/dangermouse--



********************************************************************************************
" This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only for
the person to whom it is addressed. If you are not the intended recipient, you
are not authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message ".
********************************************************************************************