

Ask HN: security vs. utility: admin priviledges - mgualt

I work at a university, and the computer services for my academic department are managed in-house by a couple of computer officers.  To maintain a secure network, they do not allow users admin privileges on any machine for which they provide support.  While I understand this point of view, (and I am aware that there are probably many potential problems that I have no knowledge of) it seems to render the network much less useful than it could otherwise be.<p>For example, my postdocs can&#x27;t install any software without clearing it with the admins in advance (and for experimenting with new software and programming languages, this is really impossible, just think of dependencies).<p>Another example: I would like to send a student to a python boot camp, but he would need admin privileges on the department laptop. It&#x27;s a no-go.<p>My question is: What is the modern &quot;right way&quot; to securely administer a network without laming it to this extent?  What is your opinion on what strategy the department should employ?
======
cbhl
I'm an undergrad at the University of Waterloo.

The way most undergrads have dealt with this problem is to buy and bring their
own device. It's gotten to the point where we exhausted our IPv4 allocation on
our eduroam (Wi-Fi) network, so a year or two back they switched eduroam to
mass NAT. (It appears that they're only just starting to add IPv6 support in,
but I digress.)

Frankly, any sysadmin worth their salt knows that admin/root access can easily
be granted in a secure network, either by using Group Policy (Windows/AD) or
by using virtualization (for client-server computing; think KVM/libvirt) or
access control (SELinux).

Edit: Need proof? Try
[http://www.coker.com.au/selinux/play.html](http://www.coker.com.au/selinux/play.html)

That said-- if you're installing new software and programming languages, you
probably shouldn't need or want root, especially if you're using Linux. The
binary packages are almost always too stale for what you're doing -- and if
you're building from source, you can set PREFIX to $HOME (so you get
$HOME/bin, $HOME/man, etc.).

For Ruby and Python in particular, rbenv and virtualenv make it a breeze to
use the language (and all the packages/gems you could want) without ever
needing to touch root.

The disadvantage of this is that now you have ten post-docs each with a copy
of Go and the GHC and Python and Ruby (and sources!) sitting in their homedir,
which means that you're now storing thirty gigabytes of source when you could
have a few megabytes of binaries. (Think about how this scales when you have
1,000 undergrads on NFS homedirs.)

But that's a trade-off that is up to your department's sysadmins to make.

~~~
IsThisObvious
I agree with what you said, just wanted to add an aside about privileges:

You can set up a situation where a team has shared access to a particular
folder, and install the necessary programming tools there.

ie, set PREFIX to /projects/MYPROJECT or similar, and then grant access to
that directory to everyone on the project team.

------
tlb
It's futile to try to learn computing without root access. Buy separate
computers to hack on, and just use the departmental computers for non-
technical stuff.

------
_cbdev
I'd probably just go with a Bring-Your-Own-Device strategy.

------
stephenr
This is what virtual machines excel at

