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
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()
As I read through LWN today, I noted the following comment,
http://lwn.net/Articles/255832/ :
Personally, I think it's absolutely essential to be able to
build a kernel with dynamic LSM. Whether we like it or not,
people do want to add in runtime loadable security
On Tue, 23 Oct 2007 10:34:09 CDT, "Serge E. Hallyn" said:
> And he will still be able to *run* the suid binary, but if cap_bound is
> reduced he won't be able to use capabilities taken out of the bounding
> set, multiadm loaded or not.
I am willing to bet that there's still a *lot* of unaudited
On Tue, 23 Oct 2007 10:34:09 CDT, Serge E. Hallyn said:
And he will still be able to *run* the suid binary, but if cap_bound is
reduced he won't be able to use capabilities taken out of the bounding
set, multiadm loaded or not.
I am willing to bet that there's still a *lot* of unaudited
As I read through LWN today, I noted the following comment,
http://lwn.net/Articles/255832/ :
Personally, I think it's absolutely essential to be able to
build a kernel with dynamic LSM. Whether we like it or not,
people do want to add in runtime loadable security
On Tue, 23 Oct 2007 17:31:28 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't
> > see anyway to help out the modular case, so I guess it will have to
> > incur the hit that's always been there.
>
>
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote:
> * Some people are not comfortable building kernels from source. It
> doesn't matter how easy *you* think it is, it is a significant
> barrier to entry for a lot of people. Especially if their day job
> is
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't see
> > anyway to help out the modular case, so I guess it will have to incur
> > the hit that's always been there.
>
> Broaden the paravirt patching
Chris Wright wrote:
> Yes, and I think we can still improve performance although I can't see
> anyway to help out the modular case, so I guess it will have to incur
> the hit that's always been there.
Broaden the paravirt patching machinery?
J
-
To unsubscribe from this list: send the line
On Sun, 21 Oct 2007, Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> > As Sarbanes-Oxley and
> > other regulatory laws require these customers to use "standard
> > kernels", the result is a rather dreary form of vendor lock-in, where the
> > security framework
On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote:
> Greg KH wrote:
>> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>>
>>> Yes, I think Crispin has succinctly summed it up: irrevocably closing
>>> the LSM prevents commercial customers from using security modules
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
>
> On Oct 23 2007 10:20, Serge E. Hallyn wrote:
> >
> >Once the per-process capability bounding set is accepted
> >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
> >like:
> >
> > 1. Create user 'jdoe' with uid 0
>
> UID 0 is
On Oct 23 2007 10:20, Serge E. Hallyn wrote:
>
>Once the per-process capability bounding set is accepted
>(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
>like:
>
> 1. Create user 'jdoe' with uid 0
UID 0 is _not_ acceptable for me.
> 2. write a pam module
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
>
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
> >
> >> I do have a pseudo LSM called "multiadm" at
> >> http://freshmeat.net/p/multiadm/ , quoting:
> >
> >> Policy is dead simple since it is based on UIDs. The UID ranges can be
> >> set on module
On Mon, October 22, 2007 18:13, Greg KH wrote:
> I agree, that is why customers do not load other random security modules
> in their kernel today, and why they will not do so tomorrow. So,
> because of that, this whole point about compliance with regulatory law
> seems kind of moot :)
>
> Again,
On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
>> So, we give caps to the subadmins (which is IMHO a natural task),
>> and then, as per LSM design (wonder where that is written) deny
>> some of the rights that the capabilities raised for subadmins grant,
>> because that is obviously too much.
On Oct 23 2007 02:13, Chris Wright wrote:
>* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
>> On Oct 22 2007 22:16, Chris Wright wrote:
>> >Yes, and I think we can still improve performance although I can't see
>> >anyway to help out the modular case, so I guess it will have to incur
>> >the hit
Jan Engelhardt wrote:
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
I do have a pseudo LSM called "multiadm" at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
> On Oct 22 2007 22:16, Chris Wright wrote:
> >Yes, and I think we can still improve performance although I can't see
> >anyway to help out the modular case, so I guess it will have to incur
> >the hit that's always been there. I think your Kconfig
On Oct 21 2007 08:57, James Morris wrote:
>> >I'd like to note that I asked people who were actually affected, and had
>> >examples of their real-world use to step forward and explain their use,
>> >and that I explicitly mentioned that this is something we can easily
>> >re-visit.
[...]
I
On Oct 22 2007 22:16, Chris Wright wrote:
>>
>> If it turns out that the above module becomes unmaintained and no
>> longer usable, and no other useful cases show up, we can always
>> garbage collect this code in the future; it's now low-overhead
>> anyway for those who care, due to the KConfig
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>
>> I do have a pseudo LSM called "multiadm" at
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> Policy is dead simple since it is based on UIDs. The UID ranges can be
>> set on module load time or during runtime (sysfs params). This LSM is
>>
Crispin Cowan wrote:
Giacomo Catenazzi wrote:
What do technical and regulatory differences have "driver/LSM module" that
is build-in and one that is modular?
It seems to me silly to find difference. A kernel with a new kernel module
is a new kernel.
*I* understand that, from a security and
Giacomo Catenazzi wrote:
> What do technical and regulatory differences have "driver/LSM module" that
> is build-in and one that is modular?
> It seems to me silly to find difference. A kernel with a new kernel module
> is a new kernel.
>
*I* understand that, from a security and logic
Giacomo Catenazzi wrote:
What do technical and regulatory differences have driver/LSM module that
is build-in and one that is modular?
It seems to me silly to find difference. A kernel with a new kernel module
is a new kernel.
*I* understand that, from a security and logic integrity point
Crispin Cowan wrote:
Giacomo Catenazzi wrote:
What do technical and regulatory differences have driver/LSM module that
is build-in and one that is modular?
It seems to me silly to find difference. A kernel with a new kernel module
is a new kernel.
*I* understand that, from a security and
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM is
basically
On Oct 22 2007 22:16, Chris Wright wrote:
If it turns out that the above module becomes unmaintained and no
longer usable, and no other useful cases show up, we can always
garbage collect this code in the future; it's now low-overhead
anyway for those who care, due to the KConfig option.
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
On Oct 22 2007 22:16, Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there. I think your Kconfig option is a
On Oct 21 2007 08:57, James Morris wrote:
I'd like to note that I asked people who were actually affected, and had
examples of their real-world use to step forward and explain their use,
and that I explicitly mentioned that this is something we can easily
re-visit.
[...]
I looked at
On Oct 23 2007 02:13, Chris Wright wrote:
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
On Oct 22 2007 22:16, Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always
Jan Engelhardt wrote:
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM
On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
So, we give caps to the subadmins (which is IMHO a natural task),
and then, as per LSM design (wonder where that is written) deny
some of the rights that the capabilities raised for subadmins grant,
because that is obviously too much.
On Mon, October 22, 2007 18:13, Greg KH wrote:
I agree, that is why customers do not load other random security modules
in their kernel today, and why they will not do so tomorrow. So,
because of that, this whole point about compliance with regulatory law
seems kind of moot :)
Again, LSM
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during
On Oct 23 2007 10:20, Serge E. Hallyn wrote:
Once the per-process capability bounding set is accepted
(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
like:
1. Create user 'jdoe' with uid 0
UID 0 is _not_ acceptable for me.
2. write a pam module which, when
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
On Oct 23 2007 10:20, Serge E. Hallyn wrote:
Once the per-process capability bounding set is accepted
(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
like:
1. Create user 'jdoe' with uid 0
UID 0 is _not_
On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote:
Greg KH wrote:
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than
On Sun, 21 Oct 2007, Greg KH wrote:
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
As Sarbanes-Oxley and
other regulatory laws require these customers to use standard
kernels, the result is a rather dreary form of vendor lock-in, where the
security framework is coupled
Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there.
Broaden the paravirt patching machinery?
J
-
To unsubscribe from this list: send the line
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there.
Broaden the paravirt patching machinery?
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote:
* Some people are not comfortable building kernels from source. It
doesn't matter how easy *you* think it is, it is a significant
barrier to entry for a lot of people. Especially if their day job
is systems or
On Tue, 23 Oct 2007 17:31:28 -0700
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Chris Wright wrote:
Yes, and I think we can still improve performance although I can't
see anyway to help out the modular case, so I guess it will have to
incur the hit that's always been there.
Broaden
Thomas Fricaccia wrote:
> Some well-respected contributors have taken exception my amplification
> of Crispin Cowan's point about the patch that closes LSM.
>
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>> * It prevents enterprise users, and in fact anyone who isn't
>> comfortable
Jan Engelhardt wrote:
> I do have a pseudo LSM called "multiadm" at
> http://freshmeat.net/p/multiadm/ , quoting:
> Policy is dead simple since it is based on UIDs. The UID ranges can be
> set on module load time or during runtime (sysfs params). This LSM is
> basically grants extra rights
On Mon, 22 Oct 2007, Crispin Cowan wrote:
Suffice it to say that there are a variety of reasons why someone either
cannot re-compile a kernel, or just does not want to recompile a kernel.
This change to LSM removes their choice to use modules others than those
provided by their distro vendor.
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
> On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> >
> > > >I'd like to note that I asked people who were actually affected,
> > > >and had examples of their
Greg KH wrote:
> On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
>
>> Security is big business, as is compliance with regulatory law. Large
>> enterprise customers are NOT going to either void their system support
>> contracts, or place themselves in jeopardy of failing a SOX
On Tue, 23 Oct 2007 14:56:52 +1000 (EST)
James Morris <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Oct 2007, Arjan van de Ven wrote:
>
> > @@ -4895,6 +4908,7 @@ static struct security_operations selinu
> > .sem_semop =selinux_sem_semop,
> >
> > .register_security =
> >
On Mon, 22 Oct 2007, Arjan van de Ven wrote:
> @@ -4895,6 +4908,7 @@ static struct security_operations selinu
> .sem_semop =selinux_sem_semop,
>
> .register_security =selinux_register_security,
> + .unregister_security =
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris <[EMAIL PROTECTED]> wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
>
> > >I'd like to note that I asked people who were actually affected,
> > >and had examples of their real-world use to step forward and
> > >explain their use, and that
Greg KH wrote:
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.
Any "customer"
On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
> To possibly save bandwidth, I'll also respond to another of Greg's points:
>
> "Greg KH" <[EMAIL PROTECTED]> wrote:
> > Any "customer" using a security model other than provided by their Linux
> > distributor instantly voided all
> The point of contention: closing LSM significantly reduces the freedom
> of an important class of Linux users, the commercial enterprises, to
> use whatever security framework they desire. Greg and Alan didn't
No it doesn't. Strange interpretations of peculiar US laws may be doing
that. Thats
Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.
Crispin Cowan <[EMAIL PROTECTED]> wrote:
> * It prevents enterprise users, and in fact anyone who isn't
> comfortable compiling their own kernel, from ever
On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote:
>
> For that reason I think keeping LSM is the right thing to do.
Wait, we aren't talking about dropping LSM at all, just the "LSM is a
module" option. That's it. And by making LSM not a module, we can then
go on to fix some of the
> > Crispin at least is providing genuine discussion points. Sarbox has
> > nothing to say on "using vendor linux kernels".
> >
> I agree that SarBox is not really the issue here. Partially related is
> enterprise rules about what kernels one is allowed to load. More
> generally, this change
Alan Cox wrote:
> On Sun, 21 Oct 2007 19:24:42 -0700
> "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote
>> Yes, I think Crispin has succinctly summed it up: irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.
On Sun, 21 Oct 2007 19:24:42 -0700
"Thomas Fricaccia" <[EMAIL PROTECTED]> wrote:
> Yes, I think Crispin has succinctly summed it up: irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor. As Sarbanes-Oxley
On Sun, 21 Oct 2007 19:24:42 -0700
Thomas Fricaccia [EMAIL PROTECTED] wrote:
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor. As Sarbanes-Oxley and
Alan Cox wrote:
On Sun, 21 Oct 2007 19:24:42 -0700
Thomas Fricaccia [EMAIL PROTECTED] wrote
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor. As
Crispin at least is providing genuine discussion points. Sarbox has
nothing to say on using vendor linux kernels.
I agree that SarBox is not really the issue here. Partially related is
enterprise rules about what kernels one is allowed to load. More
generally, this change forces users
On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote:
For that reason I think keeping LSM is the right thing to do.
Wait, we aren't talking about dropping LSM at all, just the LSM is a
module option. That's it. And by making LSM not a module, we can then
go on to fix some of the reported
Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.
Crispin Cowan [EMAIL PROTECTED] wrote:
* It prevents enterprise users, and in fact anyone who isn't
comfortable compiling their own kernel, from ever trying
The point of contention: closing LSM significantly reduces the freedom
of an important class of Linux users, the commercial enterprises, to
use whatever security framework they desire. Greg and Alan didn't
No it doesn't. Strange interpretations of peculiar US laws may be doing
that. Thats
On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
To possibly save bandwidth, I'll also respond to another of Greg's points:
Greg KH [EMAIL PROTECTED] wrote:
Any customer using a security model other than provided by their Linux
distributor instantly voided all support from
Greg KH wrote:
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.
Any customer
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected,
and had examples of their real-world use to step forward and
explain their use, and that I explicitly
On Mon, 22 Oct 2007, Arjan van de Ven wrote:
@@ -4895,6 +4908,7 @@ static struct security_operations selinu
.sem_semop =selinux_sem_semop,
.register_security =selinux_register_security,
+ .unregister_security =
On Tue, 23 Oct 2007 14:56:52 +1000 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007, Arjan van de Ven wrote:
@@ -4895,6 +4908,7 @@ static struct security_operations selinu
.sem_semop =selinux_sem_semop,
.register_security =
Greg KH wrote:
On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
Security is big business, as is compliance with regulatory law. Large
enterprise customers are NOT going to either void their system support
contracts, or place themselves in jeopardy of failing a SOX audit.
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected,
and had examples of their real-world use to step
On Mon, 22 Oct 2007, Crispin Cowan wrote:
Suffice it to say that there are a variety of reasons why someone either
cannot re-compile a kernel, or just does not want to recompile a kernel.
This change to LSM removes their choice to use modules others than those
provided by their distro vendor.
Jan Engelhardt wrote:
I do have a pseudo LSM called multiadm at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM is
basically grants extra rights unlike
Thomas Fricaccia wrote:
Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.
Crispin Cowan [EMAIL PROTECTED] wrote:
* It prevents enterprise users, and in fact anyone who isn't
comfortable compiling their
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> Yes, I think Crispin has succinctly summed it up: irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.
Any "customer" using a security
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor. As Sarbanes-Oxley and
other regulatory laws require these customers to use "standard
kernels", the result
To discuss how LSM should work, it would have been really helpful if the
OP had cc'd the LSM mailing list. I've cc'd the LSM list here ...
Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
>
>> But then I noticed that, while the LSM would remain in existence, it was
>>
On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
>
> > >I'd like to note that I asked people who were actually affected, and had
> > >examples of their real-world use to step forward and explain their use,
> > >and that I explicitly
On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote:
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected, and had
examples of their real-world use to step forward and explain their use,
and that I explicitly mentioned that
To discuss how LSM should work, it would have been really helpful if the
OP had cc'd the LSM mailing list. I've cc'd the LSM list here ...
Linus Torvalds wrote:
On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
But then I noticed that, while the LSM would remain in existence, it was
being
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor. As Sarbanes-Oxley and
other regulatory laws require these customers to use standard
kernels, the result is
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
Yes, I think Crispin has succinctly summed it up: irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.
Any customer using a security model
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> >I'd like to note that I asked people who were actually affected, and had
> >examples of their real-world use to step forward and explain their use,
> >and that I explicitly mentioned that this is something we can easily
> >re-visit.
> >
>
> I do
On Oct 19 2007 13:40, Linus Torvalds wrote:
>On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>>
>> Non-trivial modules (i.e., practically everything beyond capabilities)
>> become
>> effective only after loading policy, anyway. If you can load policy, you can
>> as well first load a security
On Oct 19 2007 13:40, Linus Torvalds wrote:
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
Non-trivial modules (i.e., practically everything beyond capabilities)
become
effective only after loading policy, anyway. If you can load policy, you can
as well first load a security module
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected, and had
examples of their real-world use to step forward and explain their use,
and that I explicitly mentioned that this is something we can easily
re-visit.
I do have a pseudo
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
> Quoting from commit 20510f2f (Convert LSM into a static interface):
> > In a nutshell, there is no safe way to unload an LSM. The modular interface
> > is thus unecessary and broken infrastructure. It is used only by
> > out-of-tree modules,
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>
> Non-trivial modules (i.e., practically everything beyond capabilities) become
> effective only after loading policy, anyway. If you can load policy, you can
> as well first load a security module without making the system insecure.
I'd like
On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> >
> > But then I noticed that, while the LSM would remain in existence, it was
> > being closed to out-of-tree security frameworks. Yikes! Since then,
> > I've been following the rush to
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
Quoting from commit 20510f2f (Convert LSM into a static interface):
In a nutshell, there is no safe way to unload an LSM. The modular interface
is thus unecessary and broken infrastructure. It is used only by
out-of-tree modules, which are
On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
But then I noticed that, while the LSM would remain in existence, it was
being closed to out-of-tree security frameworks. Yikes! Since then,
I've been following the rush to put
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
Non-trivial modules (i.e., practically everything beyond capabilities) become
effective only after loading policy, anyway. If you can load policy, you can
as well first load a security module without making the system insecure.
I'd like to
On Wed, 17 Oct 2007 18:34:16 -0700
"Thomas Fricaccia" <[EMAIL PROTECTED]> wrote:
>
> But then I noticed that, while the LSM would remain in existence, it
> was being closed to out-of-tree security frameworks. Yikes! Since
> then, I've been following the rush to put SMACK, TOMOYO and AppArmor
>
On Wed, 17 Oct 2007, Casey Schaufler wrote:
>
> The in-tree vs out-of-tree discussion is independent of LSM.
Indeed. I think there is certainly likely to be some small overlap, but I
*think* they are largely independent issues - "do we want choice in
securitu models" (a very emphatic YES as
On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
>
> But then I noticed that, while the LSM would remain in existence, it was
> being closed to out-of-tree security frameworks. Yikes! Since then,
> I've been following the rush to put SMACK, TOMOYO and AppArmor
> "in-tree".
Yeah, it did come
--- Thomas Fricaccia <[EMAIL PROTECTED]> wrote:
> ...
>
> But then I noticed that, while the LSM would remain in existence, it was
> being closed to out-of-tree security frameworks. Yikes! Since then, I've
> been following the rush to put SMACK, TOMOYO and AppArmor "in-tree".
>
> Since I
--- Thomas Fricaccia [EMAIL PROTECTED] wrote:
...
But then I noticed that, while the LSM would remain in existence, it was
being closed to out-of-tree security frameworks. Yikes! Since then, I've
been following the rush to put SMACK, TOMOYO and AppArmor in-tree.
Since I know that the
On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
But then I noticed that, while the LSM would remain in existence, it was
being closed to out-of-tree security frameworks. Yikes! Since then,
I've been following the rush to put SMACK, TOMOYO and AppArmor
in-tree.
Yeah, it did come up.
1 - 100 of 102 matches
Mail list logo
