Re: tlug: NFS question

[Karl-Max Wagner <karlmax@example.com>]

> > IMHO everything suggested so far is unnecessary complex. I'd do
> > it the following way:
> > 
> > On the server in /etc/exports:
> > 
> > I enter the user machines and the directories that are exported
> > to them ( their home directories, maybe some directories ro with
> > tools for general use ).
> 
> If the size of the exported directory does not itself impose
> significant overhead, I'll just export /home once, to keep
> maintenance simple.  Clients will pick up /home, and bypass other
> user's accounts in that space, just as they would if logging into
> the server.

You can do that. It is, however, inherently insecure. NFS being
what it is you have already to restrict the act of exportation
of directories as much as possible. I admit that my way is
somewhat more difficult to administer, but it offers at least a
minimum of security.

> 
> > I also create the home directories for the users
> 
> Yes, on the server: but only /home or its link point need be
> created on the clients.  Again, this keeps maintenance simple.
> 
> > On the clients in /etc/fstab:
> > 
> > I add the nfs directories that are to be mounted at boot time
> > from the server.
> 
> Again, only /home will be needed.

See above. Most insecure.

> Except security, which is what Rex's postings were about.
> In some way we have to assure that clients share consistent
> /etc/passwd file data, and that that data is consistent with the
> expectations of the server's filesystem.

NFS cares shit for that. It just looks at what client is allowed
to do what - and this is ridiculously easy to fake.

> However, the mounting business is set up, I need to be sure that
> users cannot access other users' home directories.  I thought
> about this again, and it seems to me that it IS a pretty serious
> problem under NFS.  If the server doesn't know anything about

"Pretty serious" is an understatement....

> usernames, it is going to trivial for someone to boot a
> workstation (or adjust the IP in their laptop), login as root,
> change their own user ID to that of the person whose data they
> would like to snoop, and mount the NFS directories from the
> server.

Exactly. To put it in other words: what I proposed is to get
the maximum of the security NFS has to offer - and this is close
to nothing.

Another danger is packet sniffing on your LAN. So, if you are
serious about security, you better consider SSH / SSL NOW.

I have to admit that I did not study the combination of any of
these with NFS, but at least with SSL I don't see any problems.
AFAIK SSH, you establish a secure channel for the port number in
question - and there's already a problem: in the case of NFS
they are selected by the portmapper and not always the same.
However, they can be set to fixed values if necessary. That
should solve it.

SSH / SSL use one time session keys and encrypted authentication.
Using them will make packet sniffing fail because there is no
plaintext on the LAN any more.

This is the ONLY way to get reasonable security. Anything else
with NFS involved will buy you so little that it is not worth
being considered.

> To protect against this, I figure that each subdirectory needs a
> file like ~/.checkname, owned by root but readable to everyone
> else.  The /etc/profile script that runs before ~/.bash_profile
> will check the content of this, and compare it with the result of
> "whoami".  If there's a discrepancy, the server knows that the
> user is spoofing his identity, and script issues an immediate
> "exit", killing the shell.
> 
> Can anyone see obvious holes in this?

Easy. Just rename you client to have an identity that fits and
you're in business. 

> Rdist certainly sounds like something I need to study.

Not much to study there. However, it is one of those notoriously
insecure r* services. One more reason to switch to SSH / SSL.

> 
> For machine-specific configuration data (the X config file, and
> the list of kernel drivers needed for a given workstation), I
> figure I can just make subdirectories in /home with the IP
> address of the workstation.  Then we set up links something like
> /home/$IP_ADDRESS/Xconfig.  This is a one-time access at startup,
> so there's no problem with overhead.

And still another reason to switch to SSH / SSL.

Let's face it: when all these services were designed security
wasn't an issue. Nets were small and populated by real hackers
only. Now hackers have an inherently strong ethic and anything
even remotely smacking like an act of malice is strictly taboo
- to an extent that thoughts about security were almost
ridiculous.

Consequently the level of security they offer is close to zero.

Things, however changed. Nowadays computers and Internet access
are a commodity and consequently the net is populated of all
kinds of folk - mostly lusers, some evil scum and some real
hackers. Evil acts, therefore, while not being very frequent,
nonetheless occur and because the ensuing damage may be
devastating it is better to be really serious about security.

Even small, disconnected LAN's nowadays are populated with a
diverse populace and in most cases trusting them a lot sure
is a Bad Thang (tm).

================================================================
"It was hell. They knew it.          Karl-Max Wagner
  But they called it                 karlmax@example.com
    W-I-N-D-O-Z-E"
================================================================
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp