public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: joe@mathewson.co.uk, linux-kernel@vger.kernel.org
Subject: Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux
Date: Wed, 5 Sep 2001 17:12:48 -0500 (CDT)	[thread overview]
Message-ID: <200109052212.RAA64901@tomcat.admin.navo.hpc.mil> (raw)
In-Reply-To: <200109051913.f85JD2K01304@ambassador.mathewson.int>

Joseph Mathewson <joe@mathewson.co.uk>:
> 
> Sorry to ask another annoying question so quickly after my SCSI problems,
> but
> 
> Does anyone know of/use a secure network filesharing system on a Linux
> network?  We currently have a room of about 10 machines, mostly Linux
> clients (some MacOS X, soon to come Sun and HP-UX boxes) and servers (all
> running Linux).
> 
> For some time now, we've been using NFS for filesharing /home and have been
> extremely concerned about security.  All the clients in theory run the same
> uids/gids, thanks to LDAP, but that doesn't stop someone plugging in an
> unauthorized machine and merrily destroying everyone's home directories.
> 
> Apparently some work was done to Kerberize various bits of NFS, and Sun
> have a secure(r) implementation in Solaris.
> 
> Does anyone know of a free (preferably easy :) way of secure Linux <->
> Linux filesharing?  Apologies if that seems like a flame, maybe I've missed
> the obvious solution.  (Preferably a solution that doesn't involve editing
> /etc/exports to only allow connections from specified IPs, because if
> someone was going to go to the length of destroying our data, they could
> fake that.  Similarly, MAC addresses.)

Free if someone already owns a .357 Magnum.... (well, cost of ammo:)....

First answer:

	Not possible.
	1. You pose an unsecured network (anyone can plug in a host)
	2. Physical access to the hosts (anyone could reconfigure a host)
	3. No physical security (anyone can get in the room, with unauthorized
	   equipment).

Kerberos won't help either - The only parts of NFS that were kerberized
was the initial mount. Everything else uses filehandles/UDP. Encryption
doesn't help either - slows the entire network down too much.

Second answer:

	1. Get physical security over the network. Prevent unauthorized
	   personnel from adding unauthorized equipment.
	2. Now prevent external logical monitoring of the network with a
	   switched environment (prevents one host from seeing traffic
	   targeted at a different host).
	3. Use kerberos for general user logins.
	4. Do not let users have direct physical access to the hosts.

Usually, you don't have enough money invested in a user lab (which is what
it sounds like) to make it worth the effort to apply.

Third answer:

	A more reasonable way is to configure the user accessable systems as
	just X terminals (no MACs though) on a switched ethernet. Configure
	the switch with	a fixed MAC address for each target (prevents hardware
	substitution). Now you can put the actual user work machines as compute
	servers in a different room. The compute servers (the ones users log
	into) can then use a physically isolated network (users can't plug
	things into it) for NFS to a file server.

This is still more extensive (and expensive) than a small lab is usually
willing to accept.

Fourth answer:

	The minimum would be to use a switched ethernet, with fixed MAC
	addressing. This prevents walk-in users from substituting equipement,
	and it limits the ability to sniff the network. Only packets destined
	for one IP would be visible, and the switch should be able to signal
	an alarm if it detects an unauthorized MAC address (as well as refuse
	to work). This still allows for NFS, and a higher throughput as well
	(each node can use the full bandwidth).

The fourth answer is more likely to be acceptable to management and the users
(the carrot is the higher performance). It doesn't help the reconfiguration
possiblity (booting a floppy with a different OS on a host already authorized
to use the network).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

  parent reply	other threads:[~2001-09-05 22:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-05 19:13 [OFFTOPIC] Secure network fileserving Linux <-> Linux Joseph Mathewson
2001-09-05 19:30 ` Fred
2001-09-05 20:17 ` Frank Schneider
2001-09-05 22:12 ` Jesse Pollard [this message]
2001-09-05 22:54   ` Dax Kelson
2001-09-06  1:17   ` John Jasen
2001-09-06  1:54     ` Kain
2001-09-06  3:37     ` Bernd Eckenfels
2001-09-06 12:39       ` Jesse Pollard
2001-09-06  9:20   ` Dominik Kubla
  -- strict thread matches above, loose matches on Subject: below --
2001-09-06 12:28 Jesse Pollard
2001-09-06 16:41 ` Mike Fedyk
2001-09-06 12:46 Jesse Pollard
2001-09-07  1:53 ` Jamie Lokier
2001-09-07 15:34 Jesse Pollard
2001-09-07 15:58 ` Jamie Lokier
     [not found] <linux.kernel.20010907025336.D7329@kushida.degree2.com>
2001-09-07 15:41 ` Aaron Denney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200109052212.RAA64901@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=joe@mathewson.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox