--- "Kazuki Omo(Company)" <[EMAIL PROTECTED]> wrote:
> Dear, Folks,
>
> Now we are planning to submit LIDS to mainline.
> (As you know, it already written for supporing LSM for several years.)
>
> When we will finish to re-write documentation and some FAQ, then
> we will be able to submit the
--- Kazuki Omo(Company) [EMAIL PROTECTED] wrote:
Dear, Folks,
Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)
When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.
Dear, Folks,
Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)
When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.
Sincerely,
OMO
Serge E. Hallyn wrote: (2007/10/09 03:00):
Dear, Folks,
Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)
When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.
Sincerely,
OMO
Serge E. Hallyn wrote: (2007/10/09 03:00):
> > from under that missunderstanding, and with people who are assuming
> > that your policy has been done, "proving" the point.
>
> I'd love to have time to finish the script but unfortunately real
> life keeps interfering and I'm going to have to go back to lurking on
> this thread.
How
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
[snipped]
I'm still waiting to see the proposed SELinux policy that does what
Smack does.
That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl-script I'm
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Ok, finally getting some time to work on this stuff once again (life
> gets really crazy sometimes). I would like to postulate that you can
> restate any SMACK policy as a functionally equivalent SELinux policy
> (with a few slight technical
Ok, finally getting some time to work on this stuff once again (life
gets really crazy sometimes). I would like to postulate that you can
restate any SMACK policy as a functionally equivalent SELinux policy
(with a few slight technical differences, see below). I've been
working on a
Ok, finally getting some time to work on this stuff once again (life
gets really crazy sometimes). I would like to postulate that you can
restate any SMACK policy as a functionally equivalent SELinux policy
(with a few slight technical differences, see below). I've been
working on a
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Ok, finally getting some time to work on this stuff once again (life
gets really crazy sometimes). I would like to postulate that you can
restate any SMACK policy as a functionally equivalent SELinux policy
(with a few slight technical
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
[snipped]
I'm still waiting to see the proposed SELinux policy that does what
Smack does.
That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl-script I'm
from under that missunderstanding, and with people who are assuming
that your policy has been done, proving the point.
I'd love to have time to finish the script but unfortunately real
life keeps interfering and I'm going to have to go back to lurking on
this thread.
How about
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote:
> > Alan Cox <[EMAIL PROTECTED]> writes:
> >
> > >> My very practical question: How do I run selinux in one container,
> > >> and SMACK in another?
> > >
> > > In the LSM model you
On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote:
> Alan Cox <[EMAIL PROTECTED]> writes:
>
> >> My very practical question: How do I run selinux in one container,
> >> and SMACK in another?
> >
> > In the LSM model you don't because you could have the same container
> > objects visible
Alan Cox <[EMAIL PROTECTED]> writes:
>> My very practical question: How do I run selinux in one container,
>> and SMACK in another?
>
> In the LSM model you don't because you could have the same container
> objects visible in different contains at the same time and subject to
> different LSMs.
Alan Cox [EMAIL PROTECTED] writes:
My very practical question: How do I run selinux in one container,
and SMACK in another?
In the LSM model you don't because you could have the same container
objects visible in different contains at the same time and subject to
different LSMs. What does
On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote:
Alan Cox [EMAIL PROTECTED] writes:
My very practical question: How do I run selinux in one container,
and SMACK in another?
In the LSM model you don't because you could have the same container
objects visible in different
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote:
Alan Cox [EMAIL PROTECTED] writes:
My very practical question: How do I run selinux in one container,
and SMACK in another?
In the LSM model you don't because you could
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> > ...
> > I wouldn't expect the whole thing to be more than a couple week's
> > work for someone who really wanted to do it.
>
> Note that Serge said "SELinux re-written on top of
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > Quoting Casey Schaufler ([EMAIL PROTECTED]):
> > > ...
> > > Good suggestion. In fact, that is exactly how I approached my
> > > first two attempts at the problem. What you get if
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
--- Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Casey Schaufler ([EMAIL PROTECTED]):
...
Good suggestion. In fact, that is exactly how I approached my
first two attempts at the problem. What you get if you take that
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
...
I wouldn't expect the whole thing to be more than a couple week's
work for someone who really wanted to do it.
Note that Serge said SELinux re-written on top of Smack, not rewrite
Serge E. Hallyn wrote:
(tongue-in-cheek)
No no, everyone knows you don't build simpler things on top of more
complicated ones, you go the other way around. So what he was
suggesting was that selinux be re-written on top of smack.
Having gone from proposing a simpler and easier to use
Eric W. Biederman wrote:
> My very practical question: How do I run selinux in one container,
> and SMACK in another?
>
In AppArmor, we plan to 'containerize' (not sure what to call it) policy
so that you can have an AppArmor policy per container. This is not
currently the case, it is just the
> My very practical question: How do I run selinux in one container,
> and SMACK in another?
In the LSM model you don't because you could have the same container
objects visible in different contains at the same time and subject to
different LSMs. What does it mean to pass an SELinux protected
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> writes:
>
> > --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Likely. Until we have a generalized LSM interface with 1000 config
> >> options like netfilter I don't expect we will have
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
>
>
>> My very practical question: How do I run selinux in one container,
>> and SMACK in another?
>
> How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
> in another?
Well the style
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
>
>> It really seems to me that the LSM as currently structured creates
>> a large barrier to entry for people who have just this little thing
>> they want to do that is not possible with any existing
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> My very practical question: How do I run selinux in one container,
> and SMACK in another?
How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
in another? How would you run SMP in one and UP in the other?
One aspect that
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> It really seems to me that the LSM as currently structured creates
> a large barrier to entry for people who have just this little thing
> they want to do that is not possible with any existing security
> module.
I honestly think that the
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>> It really seems to me that the LSM as currently structured creates
>> a large barrier to entry for people who have just this little thing
>> they want to do that is not possible with any existing
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>
>
> So it's a valid question - do we address these sorts of concerns in
> order to add flexibility, or do we keep things as simple as possible
> and say that it's up to the distro, for instance, or a
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Casey Schaufler <[EMAIL PROTECTED]> writes:
>
> > --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Likely. Until we have a generalized LSM interface with 1000 config
> >> options like netfilter I don't expect we will have grounds to
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
>
>
>> Likely. Until we have a generalized LSM interface with 1000 config
>> options like netfilter I don't expect we will have grounds to talk
>> or agree to a common user space interface. Although
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Also I'm thinking towards what do we have to do isolate the security
> module stuff in the context of a namespace. So that a person in
> a container can setup their own rules that further restrict the
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> Likely. Until we have a generalized LSM interface with 1000 config
> options like netfilter I don't expect we will have grounds to talk
> or agree to a common user space interface. Although I could be
> wrong.
Gulp. I know that many of you
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> Quoting Casey Schaufler ([EMAIL PROTECTED]):
> > ...
> > Good suggestion. In fact, that is exactly how I approached my
> > first two attempts at the problem. What you get if you take that
> > route is an imposing infrastructure that has virually
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>>
>> Perform the split up you talked about above and move the table
>> matching into the LSM hooks.
>>
>> Use something like the iptables action and match to module mapping
>> code so we can have
Quoting Casey Schaufler ([EMAIL PROTECTED]):
>
> --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
> > > Kyle Moffett <[EMAIL PROTECTED]> writes:
> > >
> > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
> > >>> SElinux is not all
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Kyle Moffett <[EMAIL PROTECTED]> writes:
>
> > On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
> >> What we want from the LSM is the ability to say -EPERM when we can clearly
> >> articulate that we want to disallow something.
> >
> > This
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can clearly
articulate that we want to disallow something.
This sort of depends
Quoting Casey Schaufler ([EMAIL PROTECTED]):
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Perform the split up you talked about above and move the table
matching into the LSM hooks.
Use something like the iptables action and match to module mapping
code so we can have multiple modules
--- Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Casey Schaufler ([EMAIL PROTECTED]):
...
Good suggestion. In fact, that is exactly how I approached my
first two attempts at the problem. What you get if you take that
route is an imposing infrastructure that has virually nothing
to
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
Likely. Until we have a generalized LSM interface with 1000 config
options like netfilter I don't expect we will have grounds to talk
or agree to a common user space interface. Although I could be
wrong.
Gulp. I know that many of you are
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Also I'm thinking towards what do we have to do isolate the security
module stuff in the context of a namespace. So that a person in
a container can setup their own rules that further restrict the
Casey Schaufler [EMAIL PROTECTED] writes:
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
Likely. Until we have a generalized LSM interface with 1000 config
options like netfilter I don't expect we will have grounds to talk
or agree to a common user space interface. Although I could be
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Casey Schaufler [EMAIL PROTECTED] writes:
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
Likely. Until we have a generalized LSM interface with 1000 config
options like netfilter I don't expect we will have grounds to talk
or agree to
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
So it's a valid question - do we address these sorts of concerns in
order to add flexibility, or do we keep things as simple as possible
and say that it's up to the distro, for instance, or a site local
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
It really seems to me that the LSM as currently structured creates
a large barrier to entry for people who have just this little thing
they want to do that is not possible with any existing security
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
It really seems to me that the LSM as currently structured creates
a large barrier to entry for people who have just this little thing
they want to do that is not possible with any existing security
module.
I honestly think that the barrier has
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
My very practical question: How do I run selinux in one container,
and SMACK in another?
How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
in another? How would you run SMP in one and UP in the other?
One aspect that SELinux
Casey Schaufler [EMAIL PROTECTED] writes:
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
It really seems to me that the LSM as currently structured creates
a large barrier to entry for people who have just this little thing
they want to do that is not possible with any existing security
Casey Schaufler [EMAIL PROTECTED] writes:
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
My very practical question: How do I run selinux in one container,
and SMACK in another?
How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
in another?
Well the style of kernel
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] writes:
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
Likely. Until we have a generalized LSM interface with 1000 config
options like netfilter I don't expect we will have grounds to talk
or agree
My very practical question: How do I run selinux in one container,
and SMACK in another?
In the LSM model you don't because you could have the same container
objects visible in different contains at the same time and subject to
different LSMs. What does it mean to pass an SELinux protected
Eric W. Biederman wrote:
My very practical question: How do I run selinux in one container,
and SMACK in another?
In AppArmor, we plan to 'containerize' (not sure what to call it) policy
so that you can have an AppArmor policy per container. This is not
currently the case, it is just the
Serge E. Hallyn wrote:
(tongue-in-cheek)
No no, everyone knows you don't build simpler things on top of more
complicated ones, you go the other way around. So what he was
suggesting was that selinux be re-written on top of smack.
Having gone from proposing a simpler and easier to use
Kyle Moffett wrote:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
This sort of depends on perspective; typically with security
infrastructure you actually want
Kyle Moffett wrote:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
This sort of depends on perspective; typically with security
infrastructure you actually want
Stephen Smalley <[EMAIL PROTECTED]> writes:
> On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
>> --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>>
>> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
>> > > Kyle Moffett <[EMAIL PROTECTED]> writes:
>> > >
>> > >> On Oct 04, 2007, at
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> ...
>
> > Good suggestion. In fact, that is exactly how I approached my
> > first two attempts at the problem. What you get if you take that
> > route is an imposing infrastructure that has virually nothing
> > to do and that adds no value to the
On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
> --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
> > > Kyle Moffett <[EMAIL PROTECTED]> writes:
> > >
> > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
> > >>> SElinux
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
> > Kyle Moffett <[EMAIL PROTECTED]> writes:
> >
> >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
> >>> SElinux is not all encompassing or it is generally
> >>> incomprehensible I
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or
On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing
--- Stephen Smalley [EMAIL PROTECTED] wrote:
...
Good suggestion. In fact, that is exactly how I approached my
first two attempts at the problem. What you get if you take that
route is an imposing infrastructure that has virually nothing
to do and that adds no value to the solution.
Stephen Smalley [EMAIL PROTECTED] writes:
On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W.
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett <[EMAIL PROTECTED]> writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a better way
Kyle Moffett <[EMAIL PROTECTED]> writes:
> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
>> What we want from the LSM is the ability to say -EPERM when we can clearly
>> articulate that we want to disallow something.
>
> This sort of depends on perspective; typically with security
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
This sort of depends on perspective; typically with security
infrastructure you actually want "... the ability to
Linus Torvalds <[EMAIL PROTECTED]> writes:
> To get back to security: I didn't want pluggable security because I
> thought that was a technically good solution. No, the reason Linux has LSM
> (and yes, I was the one who pushed hard for the whole thing, even if I
> didn't actually write any of
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote:
> > I ran firefox setuid to a different (not my main user), uid+gid, gave
> > my main account that gid as a supplemental group, and gave that uid
> > access to the X magic cookie.
>
> You need to use runxas to get any kind of real
On 10/04/2007 06:56 PM, Derek Fawcus wrote:
>
> I ran firefox setuid to a different (not my main user), uid+gid, gave
> my main account that gid as a supplemental group, and gave that uid
> access to the X magic cookie.
You need to use runxas to get any kind of real security.
-
To unsubscribe
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote:
>
> The value of SELinux (or indeed any system compartmentalising access and
> limiting damage) comes into play when you get breakage - eg via a web
> browser exploit.
well, being sick of the number of times one has to upgrade the
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote:
The value of SELinux (or indeed any system compartmentalising access and
limiting damage) comes into play when you get breakage - eg via a web
browser exploit.
well, being sick of the number of times one has to upgrade the browser
On 10/04/2007 06:56 PM, Derek Fawcus wrote:
I ran firefox setuid to a different (not my main user), uid+gid, gave
my main account that gid as a supplemental group, and gave that uid
access to the X magic cookie.
You need to use runxas to get any kind of real security.
-
To unsubscribe
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote:
I ran firefox setuid to a different (not my main user), uid+gid, gave
my main account that gid as a supplemental group, and gave that uid
access to the X magic cookie.
You need to use runxas to get any kind of real security.
Linus Torvalds [EMAIL PROTECTED] writes:
To get back to security: I didn't want pluggable security because I
thought that was a technically good solution. No, the reason Linux has LSM
(and yes, I was the one who pushed hard for the whole thing, even if I
didn't actually write any of it)
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
This sort of depends on perspective; typically with security
infrastructure you actually want ... the ability to
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can clearly
articulate that we want to disallow something.
This sort of depends on perspective; typically with security infrastructure
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a better way to
Linus Torvalds wrote:
> Security, on the other hand, very much does depend on the circumstances
> and the wishes of the users (or policy-makers). And if we had one module
> that everybody would be happy with, I'd not make it pluggable either. But
> as it is, we _know_ that's not the case.
>
On Tue, 2 Oct 2007, Bill Davidsen wrote:
>
> Unfortunately not so, I've been looking at schedulers since MULTICS, and
> desktops since the 70s (MP/M), and networked servers since I was the ARPAnet
> technical administrator at GE's Corporate R Center. And on desktops response
> is (and should be
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Bill Davidsen wrote:
And yet you can make the exact same case for schedulers as security, you can
quantify the behavior, but if your only choice is A it doesn't help to know
that B is better.
You snipped a key part of the argument. Namely:
On Wed, 3 Oct 2007, Alan Cox wrote:
>
> Smack seems a perfectly good simple LSM module, its clean, its based upon
> credible security models and sound theory (unlike AppArmor).
The problem with SELinux isn't the theory. It's the practice.
IOW, it's too hard to use.
Apparently Ubuntu is
> situations. For example, I find SELinux to be so irrelevant to my usage
> that I don't use it at all. I just don't have any other users on my
> machine
That you know about...
The value of SELinux (or indeed any system compartmentalising access and
limiting damage) comes into play when you
On Tue, 02 Oct 2007 17:02:13 -0400
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> >
> > On Mon, 1 Oct 2007, Stephen Smalley wrote:
> >> You argued against pluggable schedulers, right? Why is security
> >> different?
> >
> > Schedulers can be objectively tested. There's this
On Tue, 2 Oct 2007, Linus Torvalds wrote:
>
> I don't know who came up with it, or why people continue to feed the
> insane ideas. Why do people think that servers don't care about latency?
> Why do people believe that desktop doesn't have multiple processors or
> through-put intensive
On Tue, 2 Oct 2007, Bill Davidsen wrote:
>
> And yet you can make the exact same case for schedulers as security, you can
> quantify the behavior, but if your only choice is A it doesn't help to know
> that B is better.
You snipped a key part of the argument. Namely:
Another difference is
Linus Torvalds wrote:
On Mon, 1 Oct 2007, Stephen Smalley wrote:
You argued against pluggable schedulers, right? Why is security
different?
Schedulers can be objectively tested. There's this thing called
"performance", that can generally be quantified on a load basis.
Yes, you can have
* Christoph Hellwig <[EMAIL PROTECTED]> [2007-10-02 10:14]:
> On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote:
> > reviewed the August thread from your version 1 submission and the message I
> > take away is that the code has been well-received and looks good when
> > considered on
* Christoph Hellwig [EMAIL PROTECTED] [2007-10-02 10:14]:
On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote:
reviewed the August thread from your version 1 submission and the message I
take away is that the code has been well-received and looks good when
considered on its own
Linus Torvalds wrote:
On Mon, 1 Oct 2007, Stephen Smalley wrote:
You argued against pluggable schedulers, right? Why is security
different?
Schedulers can be objectively tested. There's this thing called
performance, that can generally be quantified on a load basis.
Yes, you can have
On Tue, 2 Oct 2007, Bill Davidsen wrote:
And yet you can make the exact same case for schedulers as security, you can
quantify the behavior, but if your only choice is A it doesn't help to know
that B is better.
You snipped a key part of the argument. Namely:
Another difference is that
On Tue, 2 Oct 2007, Linus Torvalds wrote:
I don't know who came up with it, or why people continue to feed the
insane ideas. Why do people think that servers don't care about latency?
Why do people believe that desktop doesn't have multiple processors or
through-put intensive loads? Why
On Tue, 02 Oct 2007 17:02:13 -0400
Bill Davidsen [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
On Mon, 1 Oct 2007, Stephen Smalley wrote:
You argued against pluggable schedulers, right? Why is security
different?
Schedulers can be objectively tested. There's this thing called
situations. For example, I find SELinux to be so irrelevant to my usage
that I don't use it at all. I just don't have any other users on my
machine
That you know about...
The value of SELinux (or indeed any system compartmentalising access and
limiting damage) comes into play when you get
On Wed, 3 Oct 2007, Alan Cox wrote:
Smack seems a perfectly good simple LSM module, its clean, its based upon
credible security models and sound theory (unlike AppArmor).
The problem with SELinux isn't the theory. It's the practice.
IOW, it's too hard to use.
Apparently Ubuntu is giving
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Bill Davidsen wrote:
And yet you can make the exact same case for schedulers as security, you can
quantify the behavior, but if your only choice is A it doesn't help to know
that B is better.
You snipped a key part of the argument. Namely:
1 - 100 of 154 matches
Mail list logo
