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
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
Here is a new per-process capability bounding set patchset
which I expect to send to linux-kernel soon. It makes
the capbset per-process. A process can only permanently
remove bits from it's bounding set, not add them. To
remove bits, CAP_SYS_ADMIN is currently needed. Maybe
that's not the best
>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 ther
>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 p
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Here is a new per-process capability bounding set patchset
> which I expect to send to linux-kernel soon. It makes
> the capbset per-process. A process can only permanently
> remove bits from it's bounding set, not add them. To
> remove bits, CAP_SY
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
--- 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, 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
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
--- 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, 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
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
--- 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 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 Mon, 1 Oct 2007, Serge E. Hallyn wrote:
> Here is a new per-process capability bounding set patchset
> which I expect to send to linux-kernel soon. It makes
> the capbset per-process. A process can only permanently
> remove bits from it's bounding set, not add them. To
> remove bits, CAP_SYS
Quoting James Morris ([EMAIL PROTECTED]):
> On Mon, 1 Oct 2007, Serge E. Hallyn wrote:
>
> > Here is a new per-process capability bounding set patchset
> > which I expect to send to linux-kernel soon. It makes
> > the capbset per-process. A process can only permanently
> > remove bits from it's
18 matches
Mail list logo
