limited functionality accounts (was: Re: History Files)

[marcs () ZNEP COM (Marc Slemko)]

On Sat, 15 Apr 2000, Blue Boar wrote:

> How do you enforce that?
>
> I'd be a smart ass and point out that you'd have to take away my ability
> to set the execute bit on my own files... can I can always get the
> bin from off-system, and echo blahblah >> ./a.out..

Put all user-writable directories on a filesystem mounted noexec.  Then
they can do whatever they want but can't run their own executables.  You
have to worry about shared libraries on many systems though (ie. they can
be loaded from noexec filesystems), which is a pain.

> But I don't know how'd you stop even the simple case.. no tools available?
> Set pine as the shell?  Take the x bit off every binary on the system
> for world?

I prefer to take the other approach; instead of mucking with the entire
system that has lots of stuff installed everywhere and where silly admins
and other "full" users may be able to do things that let a restricted user
do things you don't want, give the restricted user their own environment.

Put them inside a chrooted environment that has only those things that you
explicitly add.  This requires a lot of care with what you add to ensure
you understand exactly what each executable lets people do, and to ensure
you have everything that is required.  If necessary on your system, you
can make sure all binaries are statically linked.

In addition, having a chrooted environment means that it is far less
critical if they do somehow manage to do things that you didn't
anticipate, since they are very limited by the chrooted environment and
segregated from the rest of your system.

Everyone knows how many security holes in the form of buffer overflows and
others have been found (and continue to be found) in setuid programs that
can yield root.  Obviously, you don't let such users execute arbitrary
setuid programs unless you are damn sure they are secure.  However, if you
are trying to limit a user by only letting them run selected programs,
then _every_ binary that they can run can let them execute unintended code
through things such as buffer overflows.  And there are a huge number of
non-setuid binaries with such problems.  Hence the chrooted environment to
limit the impact of someone doing this.  You are still vulnerable to the
odd DoS attack, but generally the effort is very significant (ie. requires
thinking) and the rewards limited in this situation.

In some situations, you may also wish to consider configuring a per-uid
kernel IP packet filter to limit the network traffic such users can
generate, if your OS supports it.

Also be wary of special filesystems such as /proc inside the chrooted
environment.  On some systems, /proc may let you escape a chrooted
environment.  On some OSes (don't think Linux lets you, but I don't know
about that for sure...) /proc lets the user edit memory in programs they
are running.  I don't know if any OS/architecture combinations let you
actually edit the text segment directly, but if not then the attacker
could use this ability to load some large chunk of code into memory on the
heap or stack and then use a buffer overflow that only lets them inject a
very small bit of code to jump to it.  There are other ways to do this
though, but they are more program specific and don't always apply.

It definitely is possible to give users a restricted environment that lets
them use a certain well defined set of functionality with very minimal
risk of the system being compromised, and a slightly higher, but still
fairly low, DoS risk.  There are a lot of angles to look at in creating
such a system.  Since you will almost certainly miss something, no matter
how much expertise you have, having as many layers of protection (eg.
chroot, limiting the programs they can execute to "safe" ones, using a
restricted shell if they have shell access, etc.) is a must.