Hello.
Casey Schaufler wrote:
There is work required to audit, SELinux, and LSM that will be
required before Smack or any other module can really use audit
properly. Smack using audit would be nice, but there are already
interesting cases that don't require it. I have fixing up audit
on my
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
From 3bba066917dd4a8a7c368ee1d2e163c3d619bb92 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 10:33:33 -0500
Subject: [PATCH 1/3] capabilities: define CONFIG_COMMONCAP
currently the compilation of commoncap.c is determined
through Makefile logic. So there
From eb29cb5c636b310efb995a1787ac0b8f0e9a13a1 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 10:33:56 -0500
Subject: [PATCH 2/3] capabilities: introduce per-process capability bounding
set (v3)
The capability bounding set is a set beyond which capabilities
From 2a0af2a5364ab568fa603cc9fdaeeef67d82dc56 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 14:07:03 -0500
Subject: [PATCH 3/3] capabilities: reduce current's caps when reducing bset
When a task sets it's capability bounding set, ensure that
pI pE and pP
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 ++
14 matches
Mail list logo
