From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Stephan Peijnik <stephan@peijnik.at>
Cc: Greg KH <greg@kroah.com>,
Rafael Konrath <rafael.konrath@gmail.com>,
linux-security-module@vger.kernel.org,
Linux Containers <containers@lists.osdl.org>,
Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
Grzegorz Nosek <root@localdomain.pl>
Subject: Re: LSM stacking/secondary modules / RFC: Socket MAC LSM
Date: Wed, 14 Jan 2009 18:44:07 -0600 [thread overview]
Message-ID: <20090115004407.GA14867@us.ibm.com> (raw)
In-Reply-To: <20090115004143.GB14467@us.ibm.com>
(Sorry! Meant to add extra recipients!)
Quoting Serge E. Hallyn (serue@us.ibm.com):
> Quoting Stephan Peijnik (stephan@peijnik.at):
> > On Wed, 2009-01-14 at 15:16 -0800, Greg KH wrote:
> > > On Wed, Jan 14, 2009 at 11:28:51PM +0100, Stephan Peijnik wrote:
> > > > But Tuxguardian provides a different set of features and works
> > > > differently.
> > >
> > > Not entirely, SELinux provides a lot of what it sounds like Tuxguardian
> > > provides, but in a different way. If you were to mix them, it could get
> > > very messy, very quickly.
> >
> > Well, maybe I don't understand the whole concept behind LSM and/or the
> > security concept in general. But from my understanding it could, in
> > theory, be safe to have at least multiple socket MAC modules running.
> > If one denies access the others don't need to be consulted. On the other
> > hand, if all allow a specific call to be made it could be granted.
> >
> > > > Maybe this can't be solved by using the LSM framework, but come up with
> > > > something different and independent.
> > >
> > > Patches are always welcome.
> >
> > Even though I have no patches prepared I have been playing around with
> > my ideas.
> > I haven't done a lot of testing on this yet, as it is meant to be a
> > prototype only, but two implementations of a possible Socket MAC
> > subsystem can be found at http://repo.or.cz/w/linux-2.6/sactl.git.
> >
> > The subsystem is intended to be used by modules like Tuxguardian and
> > does only provide a limited set of information (ie. no direct access to
> > the relevant socket structures, only works for AF_INET and AF_INET6
> > sockets).
>
> So do you think we could come up with a usable framework using the
> idea which Paul Menage suggests here:
> https://lists.linux-foundation.org/pipermail/containers/2009-January/015280.html
> ?
>
> Basically, you would use a control group (cgroup) to track tasks.
> I.e. you might launch firefox in a separate 'webclient' cgroup.
> Traffic then gets controlled (and mangled) based on the cgroup
> of the sending/receiving task.
>
> Presumably one possible iptables target would be something which
> launches a popup window to ask the user 'should task firefox in
> cgroup webclient be allowed to access google.com'?
>
> Just wondering - and figuring these appear to be two completely distinct
> groups of people having very similar discussion...
>
> -serge
next parent reply other threads:[~2009-01-15 0:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1231952352.5315.13.camel@sp-laptop3.sp-local>
[not found] ` <1231952313.31192.27.camel@localhost.localdomain>
[not found] ` <1231952907.5315.17.camel@sp-laptop3.sp-local>
[not found] ` <1231953606.31192.41.camel@localhost.localdomain>
[not found] ` <f639a5c10901140934w3a019308yb5c5c1d73b605fd5@mail.gmail.com>
[not found] ` <20090114180129.GB7337@kroah.com>
[not found] ` <1231972131.5315.48.camel@sp-laptop3.sp-local>
[not found] ` <20090114231645.GA24111@kroah.com>
[not found] ` <1231979170.5315.69.camel@sp-laptop3.sp-local>
[not found] ` <20090115004143.GB14467@us.ibm.com>
2009-01-15 0:44 ` Serge E. Hallyn [this message]
2009-01-15 13:57 ` LSM stacking/secondary modules / RFC: Socket MAC LSM Stephan Peijnik
[not found] ` <1232027832.14136.8.camel-tVJweC8gK2XqZ64ylGF+7cM6rOWSkUom@public.gmane.org>
2009-01-15 15:35 ` Grzegorz Nosek
2009-01-15 17:29 ` Paul Menage
[not found] ` <20090115153531.GI17884-yp6mvK3Bdd2rDJvtcaxF/A@public.gmane.org>
2009-01-15 17:50 ` Stephan Peijnik
2009-01-15 17:25 ` Paul Menage
2009-01-15 17:58 ` Stephan Peijnik
2009-01-16 20:43 ` Paul Moore
2009-01-18 15:46 ` Stephan Peijnik
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=20090115004407.GA14867@us.ibm.com \
--to=serue@us.ibm.com \
--cc=containers@lists.osdl.org \
--cc=greg@kroah.com \
--cc=linux-security-module@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=rafael.konrath@gmail.com \
--cc=root@localdomain.pl \
--cc=stephan@peijnik.at \
/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