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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.