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