--- 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):
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
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
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
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
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]):
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
--- 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
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 [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] 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 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 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.
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
* 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
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, 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
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
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 RD Center. And on desktops response
is (and should be
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.
And
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
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 whole
--- 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 the wider
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 people are
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
--- 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 still be
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 inodes _or_
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
--- 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
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 ++
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 away
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
--- 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 August thread from
--- 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, Andi
--- 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 merits, but
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
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 network
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
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 environment.
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 busses
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 a
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 networks
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
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.
--- 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 with
55 matches
Mail list logo
