(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 m
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
>
-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 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
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 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
> > capa
--- 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 SELi
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 wors
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 c
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 comm
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 secur
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'
--- 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 yo
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
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 suggest
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 fo
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
>m
--- 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]> w
(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 m
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
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
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
http://
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, a
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 t
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 existin
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
--- 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 t
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 fo
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, d
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 lis
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
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
> pur
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. Con
> 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 particula
: Alan Cox; Chris Wright; Casey Schaufler; 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 Se
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!
&g
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
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 add
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
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 pr
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 yo
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
>> > ex
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:
> http://linuxdriverproject.org/twiki
Ok lets get to a good point.
Lets define a key bit. What is a good software security lock?
My define is that its available to be used everywhere its needed and
when ever its need without flaw.
This is where most LSM fall in a heap. Because you have to have the
LSM loaded to have its security
On Thu, 25 Oct 2007, Alan Cox wrote:
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 *don't* lock your bike up, as poor security is
worse than none?)
On the contrary because
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 modules and thereby making people aware that their
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 modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.
This argu
> > 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 *don't* lock your bike up, as poor security is
> worse than none?)
On the contrary because I know it is not secure I wo
On 10/24/07, Alan Cox <[EMAIL PROTECTED]> 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 se
On Thu, 25 Oct 2007 09:04:57 -0700
"Ray Lee" <[EMAIL PROTECTED]> wrote:
> Security is not an all or nothing game, it's layers. And we have to
> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how
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, I'll still
> > use them to lock up my bike and
On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
>> On 24/10/07 13:55, Adrian Bunk wrote:
>> > On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> >> I currently have an LSM that only handles permissions for socket_bind
On Wed, October 24, 2007 22:02, David P. Quigley wrote:
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate
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, I'll still
> use them to lock up my bike and garage.
The question is what the security threat is and the value o
On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote:
The scariest thing to consider is programs which don't
appropriately handle failure. So I don't know, maybe the system
runs a remote logger to which the multiadm policy gives some extra
privs, but now the portac module prevents it from se
On Wed, 24 Oct 2007 17:41:28 -0700
Chris Wright <[EMAIL PROTECTED]> 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 me
On Thu, 25 Oct 2007, 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 par
On Wed, 24 Oct 2007, Serge E. Hallyn wrote:
The scariest thing to consider is programs which don't appropriately
handle failure. So I don't know, maybe the system runs a remote logger
to which the multiadm policy gives some extra privs, but now the portac
module prevents it from sending its dat
> 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 which makes users think
* 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 one(s)?
> Chris? Casey? Crispin?
St
--- Chris Wright <[EMAIL PROTECTED]> wrote:
> * Casey Schaufler ([EMAIL PROTECTED]) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for thei
I have different deal breakers.
If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use. Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's. All enforcem
--- Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 25 Oct 2007, Adrian Bunk wrote:
> >
> > What I'm giving you is "Linus has decreed there can be LSMs other than
> > SELinux."
> >
> > Getting LSMs included should no longer be harder than for other
> > parts of the kernel.
>
> Well
On 10/24/07, Chris Wright <[EMAIL PROTECTED]> wrote:
> * Casey Schaufler ([EMAIL PROTECTED]) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "f
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.
I agree th
On Thu, 25 Oct 2007, Adrian Bunk wrote:
>
> What I'm giving you is "Linus has decreed there can be LSMs other than
> SELinux."
>
> Getting LSMs included should no longer be harder than for other
> parts of the kernel.
Well, despite my heart-felt feelings that we should support different
peo
On Wed, Oct 24, 2007 at 03:58:02PM -0700, Casey Schaufler wrote:
>
> --- Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > ...
> >
> > There are other points in this thread that might or might not warrant
> > making LSM modular again, but even though it might sound harsh breaking
> > external modul
On Oct 24 2007 18:02, David P. Quigley wrote:
>>
>> But an LSM needs to _explicitly_ call the next LSM's function. No
>> one (just a minimal grep in linux-2.6/security/) besides SELinux
>> does that today. So while you could load AppArmor ontop of
>> MultiAdm, it would never be invoked. This is w
--- Adrian Bunk <[EMAIL PROTECTED]> wrote:
> ...
>
> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel
On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
> On 24/10/07 13:55, Adrian Bunk wrote:
> > On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
> >> I currently have an LSM that only handles permissions for socket_bind
> >> and socket_listen, I load it and then "capability"
On Wed, 2007-10-24 at 14:58 -0700, Casey Schaufler wrote:
> --- "David P. Quigley" <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > > On Oct 24 2007 19:59, Simon Arlott wrote:
> > > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > > >> On Oct 24 2007 19:11
On Wed, 2007-10-24 at 23:51 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 16:37, Serge E. Hallyn wrote:
> >
> >Or, a better example, a privileged program reads some sensitive data -
> >as allowed by multiadm, writes it to a file, but apparmor prevented it
> >from chowning the file to the right user
--- "David P. Quigley" <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rul
On Oct 24 2007 16:37, Serge E. Hallyn wrote:
>
>Or, a better example, a privileged program reads some sensitive data -
>as allowed by multiadm, writes it to a file, but apparmor prevented it
>from chowning the file to the right user before writing,
Interesting find, I should pay attention to that
On Oct 24 2007 17:02, David P. Quigley wrote:
>>
>> There has been a feature in the security framework that probably did
>> not get much attention. It looks like YAGNI first, but on a closer look,
>> it becomes useful pretty quick - secondary_register.
>>
>> As more and more simple LSM plugins p
Quoting David P. Quigley ([EMAIL PROTECTED]):
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules whi
I have written Smack.
I need an LSM infrastructure.
I would prefer the old dynamic version.
I no trouble with the static version.
I think that a dynamic version is more useful, but I didn't want
what I'm doing to have it as a dependency, so I made sure that
it isn't. The debate about the inclusi
On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 19:59, Simon Arlott wrote:
> >On 24/10/07 19:51, Jan Engelhardt wrote:
> >> On Oct 24 2007 19:11, Simon Arlott wrote:
> >>>
> >>>* (I've got a list of access rules which are scanned in order until one of
> >>>them matches, a
On Oct 24 2007 13:18, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>> * (I've got a list of access rules which are scanned in order until one of
>>> them matches, and an array of one bit for every port for per-port default
>>> allow/deny - altho
Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>
>> * (I've got a list of access rules which are scanned in order until one of
>> them matches, and an array of one bit for every port for per-port default
>> allow/deny - although the latter could be removed.
>> http://svn.lp0
On Oct 24 2007 19:59, Simon Arlott wrote:
>On 24/10/07 19:51, Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>>
>>>* (I've got a list of access rules which are scanned in order until one of
>>>them matches, and an array of one bit for every port for per-port default
>>>allow
On 24/10/07 19:51, Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>* (I've got a list of access rules which are scanned in order until one of
>>them matches, and an array of one bit for every port for per-port default
>>allow/deny - although the latter could be removed.
>>h
On Oct 24 2007 19:11, Simon Arlott wrote:
>
>* (I've got a list of access rules which are scanned in order until one of
>them matches, and an array of one bit for every port for per-port default
>allow/deny - although the latter could be removed.
>http://svn.lp0.eu/simon/portac/trunk/)
Besides
On 24/10/07 13:55, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, 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
On Wed, Oct 24, 2007 at 6:55 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, 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
On Wed, Oct 24, 2007 at 12:50:29PM +0100, 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.
>
> Why can'
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.
Why can't this "static LSM" change be a Kconfig option?
(I don't want to have to m
94 matches
Mail list logo
