--- "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 p
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 a
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 w
--- 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 di
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 scrip
--- 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
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. Wh
--- 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",
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
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 secur
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 ob
--- "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 groun
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 SELin
--- "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 barr
"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 secu
"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 s
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 mult
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 e
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 so
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 is
--- 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
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 t
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 infrast
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 r
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 i
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 se
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 browser
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&D Center. And on desktops response
> is (and should b
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:
A
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 givin
> 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 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 loads?
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 tha
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 cr
* 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 it
On Sep 30 2007 01:16, Andrew Morton wrote:
>>
>> Documentation/Smack.txt | 104 +
>> security/Kconfig |1
>> security/Makefile |2
>> security/smack/Kconfig| 10
>> security/smack/Makefile |9
>> security/smack/smack.h| 207
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> Anyways; if someone wants to cripple their security for some
> performance this way they can surely do this; but i don't think we should
> offer it as a default configuration option (just as we don't have a
> CONFIG_NULL_LSM even though there are und
On Mon, Oct 01, 2007 at 11:40:39AM -0400, Stephen Smalley wrote:
> You argued against pluggable schedulers, right? Why is security
> different?
>
> Do you really want to encourage people to roll their own security module
> rather than working toward a common security architecture and a single
> b
On Mon, Oct 01, 2007 at 09:04:44AM -0700, Linus Torvalds wrote:
> For example, you security guys still debate "inodes" vs "pathnames", as if
> that was an either-or issue.
>
> Quite frankly, I'm not a security person, but I can tell a bad argument
> from a good one. And an argument that says "in
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote:
> >
> > On Mon, 1 Oct 2007, James Morris wrote:
> > >
> > > Merging Smack, however, would lock the kernel into the LSM API.
> > > Presently, as SELinux is the only in-tree user, LSM can s
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 crazy ideas in both s
On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote:
>
> On Mon, 1 Oct 2007, James Morris wrote:
> >
> > Merging Smack, however, would lock the kernel into the LSM API.
> > Presently, as SELinux is the only in-tree user, LSM can still be removed.
>
> Hell f*cking NO!
>
> You security peop
--- James Morris <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Sep 2007, Andrew Morton wrote:
>
> > So with the information which I presently have available to me, I'm
> > thinking that this should go into 2.6.24.
>
> I think the decision to merge Smack is something that needs to be
> considered in
On Mon, 1 Oct 2007, James Morris wrote:
>
> Merging Smack, however, would lock the kernel into the LSM API.
> Presently, as SELinux is the only in-tree user, LSM can still be removed.
Hell f*cking NO!
You security people are insane. I'm tired of this "only my version is
correct" crap. The w
On Sun, 30 Sep 2007, Andrew Morton wrote:
> So with the information which I presently have available to me, I'm
> thinking that this should go into 2.6.24.
I think the decision to merge Smack is something that needs to be
considered in the wider context of overall security architecture.
Smack i
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> ...
> > +A process can see the smack label it is running with by
> > +reading /proc/self/attr/current. A privileged process can
> > +set the process smack by writing there.
>
> Ok, so to control smack label transitions, basically you would
> run
On Sun, 30 Sep 2007, Andi Kleen wrote:
The authentication issues are very real, but a separate issue.
First rule of network security: don't trust the network.
This I agree with
Without authentication it's completely useless. I don't understand
how you can disregard that as "separate issue"
On Sunday 30 September 2007 4:16:18 am Andrew Morton wrote:
> - hm, netlabels. Who might be a suitable person to review that code?
> Seems that Paul Moore is the man. Maybe he'd be interested in taking a
> look over it (please?)
Yep, I've been tracking Casey's work on this since the first pa
On Sun, Sep 30, 2007 at 10:05:57PM +0200, Andi Kleen wrote:
> > but a cluster of Linux machines in a rack is roughly the same size of
> > a huge Unix server tens year ago --- and it's not like Ethernet is any
> > more secure than the PCI bus.
>
> PCI busses normally don't have routers to network
On Sunday 30 September 2007 3:07:42 pm Theodore Tso wrote:
> There are different kinds of security. Not all of them involve
> cryptography and IPSEC. Some of them involve armed soldiers and air
> gap firewalls. :-)
>
> Yes, normally the network is outside the Trusted Computing Base (TCB),
> but
> Yes, normally the network is outside the Trusted Computing Base (TCB),
Normally as in the 99.9% case.
> but a cluster of Linux machines in a rack is roughly the same size of
> a huge Unix server tens year ago --- and it's not like Ethernet is any
> more secure than the PCI bus.
PCI buss
On Sun, Sep 30, 2007 at 07:39:57PM +0200, Andi Kleen wrote:
> > CIPSO also lets systems like SELinux and SMACK talk to other trusted
> > systems (eg., trusted solaris) in a way they understand.
>
> Perhaps, but is the result secure? I have severe doubts.
As always, it depends on your environmen
Andi Kleen wrote:
- hm, netlabels. Who might be a suitable person to review that code?
Seems that Paul Moore is the man. Maybe he'd be interested in taking a
look over it (please?)
I personally consider these IP options it uses to be pretty useless. Who could
ever use that without c
> CIPSO is supported on SELinux as well.
That's no reason to extend that design mistake.
> It certainly has uses where IPSec
> is excessive. One example is someone I talked to recently that basically
> has a set of blade systems connected with a high speed backplane that
> looks like a netwo
> It does the job going off box, too.
It does not as far as I can see. The IETF seems to have had very good
reasons to never advance that draft any further.
> The authentication issues are very real, but a separate issue.
First rule of network security: don't trust the network. And you seem
to
--- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> 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 mer
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > - Smack.txt and the website seem a bit skimpy. Is there enough
> > documentation out there for someone to usefully (and, more importantly,
> > safely) start using smack?
>
> Yes that's the important thing.
>
> > - In his review of version 1,
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler <[EMAIL PROTECTED]>
> wrote:
>
> >
> > Smack is the Simplified Mandatory Access Control Kernel.
> >
>
> I don't know enough about security even to be dangerous. I went back and
> reviewed the Aug
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 merits, but selinux could probably be configured to
> do somet
> - Smack.txt and the website seem a bit skimpy. Is there enough
> documentation out there for someone to usefully (and, more importantly,
> safely) start using smack?
Yes that's the important thing.
> - In his review of version 1, Andi suggested that your ruleset traversal
> be protected
On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
I don't know enough about security even to be dangerous. I went back and
reviewed the August thread from your version 1 submission and the message I
take
77 matches
Mail list logo
