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
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
> > 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
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
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
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
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 of
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 they
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
and
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 garage.
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 many
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 security
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 would
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
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 code
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 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
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
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
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
> 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
* 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?
--- 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
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
--- 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.
>
>
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
> >
* 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
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
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
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
--- 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
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
--- "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
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
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
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
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
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,
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 -
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.
>>
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
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.
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
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
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
* 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 that
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
for their own
--- 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, despite my
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
--- 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 their own good,
* 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?
Stephen
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
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
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
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 merge them,
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
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
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't this
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 I can't
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 now
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 the
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.
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/deny -
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.
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 - although the
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, and an array of
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
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 which are scanned in
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 pop up,
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
--- 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 rules which are scanned in
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 before
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, Simon Arlott
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 as
--- 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 is IMHO
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 what is
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 modules and thereby
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
people in
101 - 188 of 188 matches
Mail list logo
