* Hans Zaunere (zaunereyahoo.com) [020906 11:57]:
>
> I'm looking to provide jail()'d root access to clients (the virtual
> private server bit). I myself have been a client on several of these
> setups, and while some are better than others, I often find missing and
> broken features - and I've never even looked at it from a security
> standpoint.
>
> Aside from the commonly known man pages/handbooks/etc is there a
> definitve source for PROPERLY setting one of these systems up?
> Something that outlines what features mean decreased security?
> Something that outlines proper layout of these systems? Then I can
> judge exactly what and what not to offer. I already have a good handle
> on security of regular systems, so something specific to the jail()'d
> environment would be best, as I'm sure there are some gotchas and such.
>
> Thank you,
>
> Hans

  Think carefully about exactly what kind of privileges your clients get. A
friend asked me recently if his users could escalate privileges if they have a
normal user account on the main server, and root inside the jail. After some
thinking we outlined a situation in which the user creates a suid binary to
escalate any user to root inside the jail, and then runs it as a normal user
outside the jail. Instant root.

  I doubt that there is a definative guide to absolutely securing a jailed
environment. It took many years just to iron simple tmp and shell env
escalations (such as IFS related issues) from most Unixes. Doubtless there are
still undiscovered situations like that which can lead to escalated
privileges.

  To resolve the situation we got above, we had him keep seperate unique UIDs
in the main system and all the jails. Normal users were disallowed any access
to any parts of the filesystem holding a jail. This is just a simple example,
but that is the kind of thing you should start thinking about when designing
systems like this.

Regards,

-- 
Benjamin Krueger
"Everyone has wings, some folks just don't know what they're for"
- B. Banzai
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186  A851 CFF0 7711 251A 4B18
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]