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
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 modu
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 s
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 systems
* 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 mach
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 i
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 ot
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 which,
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, L
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 that'
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 optio
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 look
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 o
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 integrity
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 compili
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 unl
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 real-wor
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 =
> > se
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 = selinux_unregister
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 try
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 repor
> > 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 for
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 an
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 mode
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
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
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 menti
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 ha
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 m
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, whic
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 p
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 f
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
--- 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 kno
51 matches
Mail list logo
