Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 May 2001 20:19:17 -0400 (EDT)
From:      Rob Simmons <rsimmons@wlcg.com>
To:        Andrew Gordon <arg@arg1.demon.co.uk>
Cc:        Forrest Houston <fhouston@east.isi.edu>, freebsd-security@freebsd.org
Subject:   Re: nfs mounts / su / yp
Message-ID:  <Pine.BSF.4.21.0105142017140.13694-100000@mail.wlcg.com>
In-Reply-To: <20010514235938.P10632-100000@server.arg.sj.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

You could prevent someone from unplugging the machine and masquerading as
it by using a wireless network.  That could get costly, since I would
assume these type of machines will be located in the basement of
dormitories, or somewhere in the public library :)

Robert Simmons
Systems Administrator
http://www.wlcg.com/

On Tue, 15 May 2001, Andrew Gordon wrote:

> On Mon, 14 May 2001, Forrest Houston wrote:
> 
> > The problem is further complicated though when you want the user to have
> > root access.  We have some people around here who need/want total access
> > to their machine.  However there is still the concern of the NFS
> > mounts.  What do you do in these circumstances?
> 
> I have a similar situation - workstations on an untrusted network.
> 
> The other solutions suggested in this thread are of no use to us:
> 
>   - physical security/BIOS etc: While we can probably trust the users
>     not to take a can opener to the machines, they don't need to bother:
>     just unplug the network cable and substitute their laptop and
>     masquerade as the machine in question.
> 
>   - keep user's home directories on their own workstations: useless for
>     us, these are open-access ("terminal room") machines with an itinerant
>     user population.
> 
> At the moment, the open access machines are limited to being X-terminals
> to a small number of trusted (securely located) server machines, which NFS
> mount the home directories.
> 
> However, I want to allow some of the machines to run applications locally
> to take load off the servers.  I am planning to do this:
> 
>   - On the NFS server, have entries explicitly exporting the /home
>     partition explicitly to each of the 'terminal' machines.
>     Initally, these exports will all be "mapall=nobody".
>     So far, this is no loss of security, as all the users with physical
>     access to the terminal rooms have accounts on the main servers.
> 
>   - On the terminals, use a PAM module to hook the login process
>     and obtain the username/password.  This will then perform a
>     transaction with the server, quoting the password, and the server
>     will change the export to be "mappall=xxx".
> 
> I'm not quite sure how best to implement this; one possibility is to use
> ssh (in password-authenticated mode) to execute a setuid program on the
> server - the setuid program will then adjust the export based on the real
> uid with which the program is executed.  Using ssh has the merit of
> protecting the password across the network without the trouble of
> inventing my own scheme (& the related risk of cockup in the design).
> There may be some DoS risks in this scheme, but in our environment that's
> fairly acceptable - there are plenty of ways for users to DoS already, and
> so long as we have audit trail we can beat them up accordingly.
> 
> If anyone can see glaring holes in this, I'd be glad to know about it
> before I get started!
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE7AHYIv8Bofna59hYRA9mKAKCj0s+mI2agiFXGMvu9pbAT7dhRawCgheRl
/kMa5fvd2gSeRb/1xcaMy3c=
=6AsY
-----END PGP SIGNATURE-----



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105142017140.13694-100000>