mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter Dolding" <oiaohm@gmail.com>
To: "Crispin Cowan" <crispin@crispincowan.com>
Cc: rmeijer@xs4all.nl, apparmor-dev@forge.novell.com,
	"LSM ML" <linux-security-module@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Arjan van de Ven" <arjan@infradead.org>
Subject: Re: [Apparmor-dev] Re: AppArmor Security Goal
Date: Fri, 16 Nov 2007 08:58:36 +1000	[thread overview]
Message-ID: <e7d8f83e0711151458t3d4349d0k1b7ce4b030db87af@mail.gmail.com> (raw)
In-Reply-To: <47395F00.6080507@crispincowan.com>

> > What is left unspecified here is 'how' a child 'with its own profile' is
> > confined here. Are it is confined to just its own profile, it may that
> > the "complicit process" communication may need to be wider specified to
> > include this.

Sorry have to bring this up.  cgroups why not?  Assign application to
a cgroup that contains there filesystem access permissions.   Done
right this could even be stacked.  Only give less access to
application unless LSM particularly overrides.

Comtainers allow overriding / in chroot style.  This needs file or
label based protection no matter the security framework.  So we don't
have the chroot problems of applications breaking out.

Apparmors file access control features along with selinux's as a
combined into a cgroup would be good.

Same is required for device control.

There are reasons why I keep on bring containers up it changes the
model.  Yes I know coming to a common agreement in these sections will
not be simple.   But at some point it has to be done.

  reply	other threads:[~2007-11-15 22:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <10657.80.126.27.205.1194933072.squirrel@webmail.xs4all.nl>
2007-11-13  8:23 ` Crispin Cowan
2007-11-15 22:58   ` Peter Dolding [this message]
2007-11-17  1:08     ` More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal) Crispin Cowan
2007-11-17  7:57       ` Peter Dolding
2007-11-17 19:22         ` Casey Schaufler
2007-11-18 11:35           ` Peter Dolding
2007-11-18 19:25             ` Crispin Cowan

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=e7d8f83e0711151458t3d4349d0k1b7ce4b030db87af@mail.gmail.com \
    --to=oiaohm@gmail.com \
    --cc=apparmor-dev@forge.novell.com \
    --cc=arjan@infradead.org \
    --cc=crispin@crispincowan.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=rmeijer@xs4all.nl \
    /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®