[Wylug-help] Guest account for Linux??

[Adam Linford]

I've had guest accounts set up with *nix boxes and these are the two ways
I've done it.

Option 1 - not really secure but quick

- create a new secluded user group (man groupadd)
- create the guest user (useradd), using the -e switch to define an expiry
time for the account, and make sure you use rbash (restricted bash) for the
user's shell (man bash for more info).  In a nutshell it stops the user from
changing directory, issuing a command with a / in it, access a file with a /
in its path, and prevents alteration of PATH ENV etc.  add that use to your
new group.

- make a directory for only the programs you want the guest to use
- create symlinks to those programs and locate them in that newly created
directory (man ln)
- chmod 555 the directory
- create the users .profile to specify the correct shell and path is
exported, and chmod 444 the .profile

Now your main problems are linked to the programs you give the account
access to.. which unfortunately is quite a lot! (read up on shell escapes
particularly).  But if you monitor your logs and make sure your system isn't
containing the digital equivalent to the crown jewels in terms of important
data, this could work for you.

Option 2 - Secure approach

Chroot jail.  This one is a bit more laborious to set up, but entirely more
interesting.

When a running process executes chroot, the root directory for that process
is altered, and the rest of the system fails to exist to it.  It is used
often with application processes to add security.  An simple example of
doing this with a user could be..

# cd /home/guest
# mkdir bin lib tmp dev
# cp /bin/ls /bin/cd /bin/bash bin/

That creates our mini system-within-a-system (in v.v.v barebones form).  The
problem now is that most programs require libraries to load.. so now we have
to..

# cd /home/guest/bin
# ldd ls
	librt.so.1 => /lib/librt.so.1 (0x40024000)
        libc.so.6 => /lib/libc.so.6 (0x40037000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40151000)
        /lib/ld-linux.so.2 (0x40000000)
# cp /lib/librt.so.1 /lib/libc.so.6 /lib/libpthread.so.0 /lib/ld-linux.so.2
/home/guest/lib/

Repeat ad-inifinitum here to sort out all the program dep's.

Add some devices..

# mknod /home/guest/dev/null c 1 3
# mknod /home/guest/dev/zero c 1 5

(you can get the min. and max. device numbers you need to pass to mknod from
copying the details you get when running ls -l /dev/null /dev/zero etc)

You can then try out your restricted filesystem with..

# chroot /home/guest /bin/bash
(chroot needs two arguments.. the path, and the command to run)
 
If you now run ls -l /, you will only see the contents of your /home/guest
as if it were the system root.

This way no matter what gets compromised, its not system wide, although you
need to make sure as little as possible goes on in your chroot jail with
root permissions, as that makes it easy to break.

You would need a load more work to get the whole thing up and running
properly so that when a user logs in they log straight into your chroot'd
filesystem.  If you decide to go for this option, strace is your friend in
discovering what system calls each program makes, in order to copy the
associated programs and libraries to your chroot jail to make everything
work.

P.S. keep track of the command history as you do it.. you can use that to
create scripts that will set up individual chroot jails for specific
applications with security concerns (ftp anyone?)

Cheers,
Adam