Re: [school-discuss] authorization management

[Harry McGregor <micros@osef.org>]

On Sun, 2003-12-14 at 12:36, Jake Maul wrote:
> Greetings,
> 
> I recently had a nightmare about a malicious high school student using 
> the do_brk() kernel vulnerability to get root on one of our linux boxes 
> and realized we really needed better protection against this kind of 
> thing (local exploits).

Local exploits are an issue, and you can do a few things about it.  Of
course you have to keep uptodate with the current security issues.

> One of the things on my list is per-user accounts, rather than a single 
> 'student' account (for accountability).

Um, one 'student' account is a very very bad idea.  Per user
authentication is a must.

>  At the moment we're using a 
> single account for all student access. KDE logs into it automatically, 
> so we don't even give out the password for it, and we use the KDE Kiosk 
> framework to limit/eliminate GUI console access.

If all your talking about is workstations, I think you are going to have
to take a bit of a more realistic approach to security.  Locking down a
workstation fully is almost impossible, as physical access is granted.

Things you need to do to start locking a workstation down:
		No bootable media (no cdroms, no floppy drives, no bootable USB
devices)
		Lilo or Grub password protected
		MD5 based passwords
		Accounts that do not need a shell access should have /bin/nologin or
/bin/false set as default shell
		/tmp should be it's own partition and mounted no-exec.

Even with these, local exploits can happen.  I would be sure that you
don't have any ssh lazy keys on the workstations, and that servers are
set to keep students from being able to ssh into them, etc.

Kernel exploits are few and far between, but they are the hardest to
handle, as you have to reboot to fix them.  I have several servers that
don't permit user interactive login that I have yet to upgrade... Of
course they are starting to hit the >600 day uptime range.

One of the longest uptimes recorded by netcraft (www.treefort.org, in
the 1200 day range) was running on FreeBSD 2.2.6, and probably had been
owned in multiple ways over time.  It just lost it's uptime due to a UPS
failure.  Keeping your OS current is critical, no matter what OS you are
running.

> How do you manage per-user accounts, spread over multiple client PCs? 
> NIS? LDAP? Manually copied /etc/{passwd,shadow,group} and NFS homedirs?

We are currently using NIS at Corbett, though will probably move to LDAP
soon, as we have used it elsewhere commercially (We are using LDAP at my
office of USGS, etc)

> Now, as it happens, we run OSX servers most everywhere. Each school has 
> one that maintains WebDAV lockers for each student (well, not yet, but 
> theoretically). My understanding of the system is that the WebDAV server 
> just talks to an LDAP (or it might be NetInfo (Apple's directory 
> service)) server that does the authentication, in which case I could 
> talk directly to that server and then somehow mount the locker either as 
> the student's home directory, or as a directory inside a local home 
> directory (eg: still using a generic local system account, with an 
> additional per-user layer on top).

You should be able to mount the homedir via NFS from the OS-X server,
and should be able to use LDAP auth to the apple directory server.

>  One of my upcoming tasks is to get 
> the lockers working on the linux boxes anyway, so if I could link the 
> authentication to it I'd get 2 for 1. In any case, eventually I'll have 
> to solve both problems somehow...
> 
> How do you guys do it?
> 
> Thanks in advance,
> Jake

			Harry