(finally starting to make headway through this thread over a month late)
Quoting Alan Cox ([EMAIL PROTECTED]):
> > To reject an LSM for providing "bad" security, IMHO you should have to
> > show how it is possible to subvert the self-stated goals of that LSM.
> > Complaints that the LSM fails to
(finally starting to make headway through this thread over a month late)
Quoting Alan Cox ([EMAIL PROTECTED]):
To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Peter Dolding wrote:
> > On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
> >> Posix capabilities predate SELinux. SELinux is not interested in
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Dolding wrote:
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Posix capabilities predate SELinux. SELinux is not interested in
Posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Dolding wrote:
> On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>> Posix capabilities predate SELinux. SELinux is not interested in
>> Posix capabilities.
>>
>>> But no IBM had to do it.
>>
Tetsuo Handa wrote:
> I think there are two other problems regarding LSM.
>
> (1) There is only one "struct security_ops" structure in the system.
>
> (2) There is only one "void *security" field in "struct task_struct".
>
>
> Years ago, there was only one MAC implementation (i.e. SELinux)
> in
Tetsuo Handa wrote:
I think there are two other problems regarding LSM.
(1) There is only one struct security_ops structure in the system.
(2) There is only one void *security field in struct task_struct.
Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Dolding wrote:
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities.
But no IBM had to do it.
Err, no. It was
On 11/1/07, David Newall <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> > On Nov 1 2007 12:51, Peter Dolding wrote:
> >
> >> This is above me doing code. No matter how many fixes I do to the
> >> core that will not fix dysfunction in the LSM section. Strict
> >> policies on fixing the
On 11/1/07, David Newall [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to
On Nov 1 2007 12:51, Peter Dolding wrote:
>
>This is above me doing code. No matter how many fixes I do to the
>core that will not fix dysfunction in the LSM section. Strict
>policies on fixing the main security model will be required.
If there is no one wanting to fix the existing code, then
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to fix the existing code, then the
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to
On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>
>
> > Improvements to the single security framework are getting over looked.
>
> Please post proposed patches.
>
> > I would have personally though selinux would have done Posix file
> >
--- Peter Dolding <[EMAIL PROTECTED]> wrote:
> Improvements to the single security framework are getting over looked.
Please post proposed patches.
> I would have personally though selinux would have done Posix file
> capabilities as a general service to all.
Posix capabilities predate
The Clear and Important thing is there is already a single security framework.
The single security framework is the security that exists when no LSM
is loaded. It turns out the more I look most of my model already
exists just not being used effectively. There is a capabilities frame
work at
2007/10/31, Crispin Cowan <[EMAIL PROTECTED]>:
> Peter Dolding wrote:
> > Lets end the bitrot. Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community
On 10/31/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Peter Dolding wrote:
> > Lets end the bitrot. Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security
On 10/31/07, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community
2007/10/31, Crispin Cowan [EMAIL PROTECTED]:
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community cannot agree
The Clear and Important thing is there is already a single security framework.
The single security framework is the security that exists when no LSM
is loaded. It turns out the more I look most of my model already
exists just not being used effectively. There is a capabilities frame
work at
--- Peter Dolding [EMAIL PROTECTED] wrote:
Improvements to the single security framework are getting over looked.
Please post proposed patches.
I would have personally though selinux would have done Posix file
capabilities as a general service to all.
Posix capabilities predate SELinux.
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Improvements to the single security framework are getting over looked.
Please post proposed patches.
I would have personally though selinux would have done Posix file
capabilities as a
Peter Dolding wrote:
> Lets end the bitrot. Start having bits go into the main OS security
> features where they should be.
>
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community cannot agree on a
one-true-standard for what that OS
On Wed, 31 Oct 2007, Peter Dolding wrote:
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking
--- Peter Dolding <[EMAIL PROTECTED]> wrote:
> Lets end the bitrot. Start having bits go into the main OS security
> features where they should be.
Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Oct 2007, Peter Dolding wrote:
>
> > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
> > applied over using Selinux rules. This is just the way it is stacking LSM's
> > is Just not healthy you
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking LSM's
is Just not healthy you always risk on LSM breaking another. Part of the
reason why I have
Jan Engelhardt wrote:
I disagree.
Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case
On Oct 30 2007 12:14, Casey Schaufler wrote:
>
>while others including SELinux will go their own ways. So long
>as LSMs are self contained and strictly restrictive the
>mechanisms they use to modulate their behavior shouldn't be an
>issue. If SELinux chooses to turn its MLS controls off between
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> (please do not drop Cc, or I would have lost this thread part if I had
> not been on lkml. And sometimes I am not because of the volume. Thanks.)
>
> On Oct 30 2007 15:13, Peter Dolding wrote:
> >On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]>
(please do not drop Cc, or I would have lost this thread part if I had
not been on lkml. And sometimes I am not because of the volume. Thanks.)
On Oct 30 2007 15:13, Peter Dolding wrote:
>On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
>> * I have no clue what family to put MultiADM
On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
> On 10/25/07, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> > []
> > > Key-based masterlocks are easily broken with freon, and their combo
> > > locks are easily brute-forced in about ten
On Oct 30 2007 01:50, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> Apparmor tutorial (beats any FAQ at first):
>> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>>
>Thanks for the high praise. Unfortunately that FTP site seems to not be
>working. Some alternatives:
[...]
On 10/30/2007 5:40 PM, Jan Engelhardt wrote:
On Oct 30 2007 12:23, Toshiharu Harada wrote:
Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in
Jan Engelhardt wrote:
> Apparmor tutorial (beats any FAQ at first):
> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
* My personal copy of the above video
On Oct 30 2007 12:23, Toshiharu Harada wrote:
>
> Instead of pushing TOMOYO Linux, I started developing
> comparison chart of security-enhance Linux implementations.
> The current version can be found in
>
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
Smack Security Model: autolabel,
Jan Engelhardt wrote:
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
* My personal copy of the above video
On Oct 30 2007 12:23, Toshiharu Harada wrote:
Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
Smack Security Model: autolabel, as far
On 10/30/2007 5:40 PM, Jan Engelhardt wrote:
On Oct 30 2007 12:23, Toshiharu Harada wrote:
Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in
On Oct 30 2007 01:50, Crispin Cowan wrote:
Jan Engelhardt wrote:
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
[...]
On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
On 10/25/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[]
Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet,
(please do not drop Cc, or I would have lost this thread part if I had
not been on lkml. And sometimes I am not because of the volume. Thanks.)
On Oct 30 2007 15:13, Peter Dolding wrote:
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
* I have no clue what family to put MultiADM or
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
(please do not drop Cc, or I would have lost this thread part if I had
not been on lkml. And sometimes I am not because of the volume. Thanks.)
On Oct 30 2007 15:13, Peter Dolding wrote:
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
On Oct 30 2007 12:14, Casey Schaufler wrote:
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
Jan Engelhardt wrote:
I disagree.
Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking LSM's
is Just not healthy you always risk on LSM breaking another. Part of the
reason why I have
On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking LSM's
is Just not healthy you always risk on
--- Peter Dolding [EMAIL PROTECTED] wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you
On Wed, 31 Oct 2007, Peter Dolding wrote:
On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking LSM's
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community cannot agree on a
one-true-standard for what that OS
On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Ah! So the proposal really is to have an LSM maintainer for each
> "family" of models, acting as a resource and arbiter for modules in a class.
I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of
On 10/25/2007 9:41 AM, Chris Wright wrote:
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be "LSM maintainers" in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the
On 10/25/2007 10:42 AM, Casey Schaufler wrote:
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like "name based access
control is rediculous", and "a module can't
--- Rob Meijer <[EMAIL PROTECTED]> wrote:
> > * The proposal only allows a single implementation of each formal
> > model. In theory, theory is just like practice, but in practice it
> > is not. SMACK and SELinux follow substantially similar formal
> > models (not exactly
Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also would require module builders to
>>>
On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>> modules as proposed, alternatively a maintainer for each formal model
>> may be more appropriate. This also would require module builders to
>> first
>> think about what
On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model. Problems:
>
> * What qualifies as a formal model? This becomes an arbitrary litmus
> test,
Rob Meijer wrote:
> What may be even more relevant are those concepts that couldn't be done
> in SELinux, and how proposals that come from the theory of alternative
> access controll models (like object capability modeling) are dismissed
> by the aparently largely MLS/MAC oriented people on the
On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
>
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and
On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like name based access
control is rediculous, and a module
Rob Meijer wrote:
What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.
On 10/29/07, Crispin Cowan [EMAIL PROTECTED] wrote:
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some formal model. Problems:
* What qualifies as a formal model? This becomes an arbitrary litmus
test, depending
On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to
first
think about what formal
--- Rob Meijer [EMAIL PROTECTED] wrote:
* The proposal only allows a single implementation of each formal
model. In theory, theory is just like practice, but in practice it
is not. SMACK and SELinux follow substantially similar formal
models (not exactly the same)
Rob Meijer wrote:
On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to
first
think
On 10/25/2007 10:42 AM, Casey Schaufler wrote:
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like name based access
control is rediculous, and a module can't be
On 10/25/2007 9:41 AM, Chris Wright wrote:
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the existing
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
Ah! So the proposal really is to have an LSM maintainer for each
family of models, acting as a resource and arbiter for modules in a class.
I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses
On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
>
On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant.
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of
Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In
r; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM c
er.kernel.org; [EMAIL PROTECTED];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
>
> Hi!
Hi!
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
>
> (So, I take
Hi!
> but require unreasonable interface changes. As people who care
> about security (y'all who are only from the LKML are excused) it
> is our obligation to look beyond the preconceived notions of what
> is and isn't secure. Security is subjective. It's how you feel
> about it.
Hmm. So lets
Hi!
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.
sarcasmHmm. So lets
Hi!
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
(So, I take it that you
];
Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
static interface)
Hi!
The idea that poor security is worse than
Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
static interface)
Hi!
The idea that poor security is worse than no security
Alan Cox wrote:
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In particular stuff
To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of
On 10/29/07, Crispin Cowan [EMAIL PROTECTED] wrote:
To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture
On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan [EMAIL PROTECTED] wrote:
To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is
Hello.
Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.
I think there are two other problems
Hello.
Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then capability as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.
I think there are two other problems regarding LSM.
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into
On 26/10/07 16:58, Greg KH wrote:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>> > I'm trying to compile a list of all known external modules and drivers
>> > and work to get them included in the main kernel tree to help
On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
>
> On Oct 25 2007 19:56, Greg KH wrote:
> >
> >I'm trying to compile a list of all known external modules and drivers
> >and work to get them included in the main kernel tree to help prevent
> >these kinds of things. If you know of
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > I'm trying to compile a list of all known external modules and drivers
> > and work to get them included in the main kernel tree to help prevent
> > these kinds of things. If
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> Which reminded me of the TuxGuardian LSM[1] - another of the real-world
> uses to meet Linus's criteria? ("had examples of their real-world use to
> step forward and explain their use")
>
> In this specific project, LSM is used to collect up calls to
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>> Am 25.10.2007 00:31 schrieb Adrian Bunk:
>> > Generally, the goal is to get external modules included into the kernel.
>> > [...] even though it might sound harsh breaking
>> >
On Oct 25 2007 19:56, Greg KH wrote:
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things. If you know of any that are not on the list at:
>
On Oct 25 2007 19:56, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that are not on the list at:
Jan Engelhardt [EMAIL PROTECTED] writes:
Which reminded me of the TuxGuardian LSM[1] - another of the real-world
uses to meet Linus's criteria? (had examples of their real-world use to
step forward and explain their use)
In this specific project, LSM is used to collect up calls to bind()
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
Am 25.10.2007 00:31 schrieb Adrian Bunk:
Generally, the goal is to get external modules included into the kernel.
[...] even though it might sound harsh breaking
external
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know
On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
On Oct 25 2007 19:56, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that
1 - 100 of 292 matches
Mail list logo
