Re: Advice on setting up a shell server
Kevin Brunelle <[email protected]>
| Newsgroups | gmane.os.netbsd.help |
|---|---|
| Message-ID | <[email protected]> |
On Tuesday 16 January 2007 19:51, James K. Lowden wrote: > Isaac Wagner-Muns wrote: > > I'm trying to set up a small shell account server for students at my > > school, and it seems to be quite a vast undertaking, mostly because > > of the security issues brought up by letting semi-anonymous people > > access my machine. I run a machine like this for 6-9 remote users... all who I know, in passing, and I trust, for the most part. You will want some way to verify the users setting up accounts (although you could automate it). The important thing is to make sure that you have conservative limits set in login.conf for those users. And to patch religiously. Also, install audit-ports and never EVER install a package with a vulnerability. And patch your packages as soon as you know of a problem. This doesn't make you immune... but it does reduce the risk. Keep tabs on any users who are using a lot of resources or are going things you don't expect with your system. Mount /tmp and /var as "noexec and nosuid" and /usr as "read-only". And /home needs to be mounted "nosuid" just in case (mount it noexec if you don't want them having easy to use shell scripts -- they can still create them). Yes, make all these partitions. And do obey these recommendations because they stop a lot of problems in their tracks. Make all the compilers "chmod o-x" and either change their group for people who need to use them or leave it as wheel and don't let any remote users compile things. And if you need to let a user compile something... change the group and then add them to the new group. It makes it a lot harder for them to do nasty things... not impossible but harder. Then make sure you get a secure copy of the files in /etc/mtree... on another system... so you have at least a sha1 to compare if you think a file might have changed. You may also want to do other checksums for all the files on the system (before you add any users) and keep it in a secure spot. Just as a way to verify. Hmm, that's all I can think of off the top of my head. Also, as soon as you patch or upgrade... make sure you also get a fresh copy of the new mtree files and other checksums if you keep them. This method isn't 100% secure but it's a strong step in the right direction and certainly stops most amateurs. > > > Is having publicly runnable shell scripts insecure? > > Not as such. Shell scripts ship with NetBSD in /usr/bin. What you want > to avoid is shell scripts that are setuid and owned by root. That's known > to be unsecurable. This is also the reason they don't run as root, even when setuid root. Test it... shell scripts can't be setuid. If you want a shell script to run as root (or whatever other user) all the time, you need to go out of your way to create a setuid wrapper program for it. I've had the need before (for a non-root account) and know that it's not a trivial task. -Kevin