newbie vserver/auth question.
solar at openwall.com
Mon Mar 28 08:31:39 PST 2005
Disclaimer: I'm not involved with LFS or HLFS, in fact I'm not even a
user. I'm just kind of a guest on this mailing list. Thus, I'm not
sure if my opinion is desirable, but here goes anyway:
On Mon, Mar 28, 2005 at 10:10:14AM -0500, Robert Connolly wrote:
> I've never used vserver. There's a few homepages for it so I'm not sure if
> they are all for the same thing. It looks alright. It looks like a user
> chroot environment with firewall integration.
I've never used vserver, but I did browse through the vserver kernel
patches on some occasions.
The main problem behind vserver's approach is that it's based on a
sort of blacklisting, -- that is, the kernel patch tries to cover every
possible syscall, ioctl, etc. which needs to be virtualized. If it
would fail to cover just one, or if one would be added in a new base
kernel version but its coverage not added to the kernel patch in time,
we have a security hole.
A better approach would have been to divide the full 32-bit UID/GID
space between virtual environments, mapping portions of that space
onto virtualized UIDs/GIDs used by particular VEs.
> It's best to have services that handle virtual users. I think cvs can do this,
> I'm not sure if apache can. Most services rely on unix permissions, for user
> read/write rights. If the service can handle this itself, then the user has
> much less access to the system while still being able to do what they need to
> do. The service would need some database to handle this, services like apache
> don't, but they could in theory.
Robert, I disagree with you on this. A service which has its own
userbase and its own access controls and which does not employ any
OS-level separation between its user accounts is less secure than a
service which does employ OS-level separation (instead of or in
addition to its own access controls). Really, either of these might
pose the same level of risk to security of the underlying OS (and to
its other services), however only the services that employ OS-level
separation guarantee that the level of separation between their user
accounts is provably no worse than that offered by the underlying OS.
> The main short-coming with normal chroot's is that the users inside them are
> still real and have real user accounts.
If you make use of an UID anywhere on the system (even within a chroot
jail), it is most appropriate to allocate it in the global /etc/passwd
as well, to ensure that it won't be taken for another purpose. This
has no security consequences. You have numerous pseudo-users in there
Just my $0.02.
More information about the hlfs-dev