NFS, password transparency, and security
I have a situation where my superiors are leaning heavily on me to make
life more convenient for them by having total availability of data from
a group of machines. They basically want to log into any one machine
within this group with the same password, and be able to access any
disks they choose from any pariticular machine (within this group).
What makes me nervous is that is that I have little to no control over
the network. The particular setup at our university is that every
single ethernet drop has a unique and world accessible IP (most of this
is done with DHCP, so most change, but the machines that have purposes,
like the afformentioned group - don't). These machines also share
subnets with machines I don't control, which makes using non-encrypted
authentication even more dangerous than usual - it is a switched
network, but that doesn't protect against much at all. The best I can
do to keep these machines from being affected from the world is to have
iptables firewalls set up on each of them, basically denying everything
including pings from outside specified subnets. This is a less than
desirable solution, not to mention the scalability issues inherent with
every single machine having its own set of firewall rules.
What I am curious to know what is the best way possible to implement
what they want and to do so as securely as possible. I work for several
University astronomers who basically want something like what they're
used to at other places: a pure sun shop, running NIS and NFS. While
I'm aware that this can be done just as easily with Linux, I am going to
assume that many places who run NIS/NFS do so inside a strictly internal
network, not on several Machines that have external IPs to themselves on
subnets shared by student lab machines and other untrusted nodes.
What I have done so far is just have a few users's home directories
mounted over NFS on a central machine, making sure that they have the
same UIDs across the board. I am rapidly realizing that this solution
does not scale well, plus it does not provide a full solution.
I apologize in advance for any rambling or over-generalizations. Please
add any advice or corrections you may have.
Thanks,
Rob
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: