From: Colin Walters <walters@verbum.org>
To: linux-kernel@vger.kernel.org
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [patch 1/3] lsm: add bsdjail module
Date: Sun, 21 Nov 2004 20:51:55 -0500 [thread overview]
Message-ID: <1101088315.3987.40.camel@nexus.verbum.private> (raw)
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
[ Sorry for the lack of References, I'm not on this list and had to grab
the message from the web archives ]
> On Iau, 2004-10-07 at 00:26, Andrew Morton wrote:
> > I don't recall anyone requesting this feature. Tell me why we should add
> > it to Linux?
>
> Subject to the code cleanups and stuff you've noted I'd actually like to
> see BSD jail stuff in our security modules because it has the virtue of
> simplicity. If it can be extended to do all of vserver even better. J
> Random Admin has a good chance at configuring BSD jails etups. J Random
> Admin needs some serious tools that don't exist to set up SELinux the
> same way.
>
> In the security world simplicity is often a virtue, both in code and
> concepts.
BSD jails are a kind of halfway point on the
"access control <-> virtualization" sliding scale. Certainly, using
SELinux for virtualization is not trivial, and I think that's fine; it
is not its intended purpose. But let's be honest - using BSD jails for
strong access control ("security") has its own downsides. For example,
now J Random Admin has N rpm/dpkg databases to manage on the same system
instead of one. Or they have hand-rolled chroots which need their own
special treatment, scripts, etc.
In other words, BSD jails and SELinux are certainly not the same thing.
This becomes more obvious when you realize that hey - SELinux is still
useful inside a BSD jail. Why should the cracked sendmail daemon be
able to destroy your configuration and the rest of the chroot? You
might even want BSD jails to enforce different SELinux policies.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2004-11-22 1:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-22 1:51 Colin Walters [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-10-06 20:21 (patch 1/3) lsm: add control over /proc/<pid> visibility Serge Hallyn
2004-10-06 20:24 ` [patch 1/3] lsm: add bsdjail module Serge Hallyn
2004-10-06 23:26 ` Andrew Morton
2004-10-07 4:08 ` Serge E. Hallyn
2004-10-07 6:18 ` James Morris
2004-10-07 6:22 ` Andrew Morton
2004-10-07 16:06 ` Chris Wright
2004-10-07 18:40 ` Andrew Morton
2004-10-07 18:52 ` Chris Wright
2004-10-07 20:56 ` Serge E. Hallyn
2004-10-10 6:24 ` Herbert Poetzl
2004-10-07 12:06 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1101088315.3987.40.camel@nexus.verbum.private \
--to=walters@verbum.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®