Prev: vhost-net: avoid flush under lock
Next: [PATCH] ecryptfs: dont call lookup_one_len to avoid NULL nameidata
From: Pavel Machek on 5 Aug 2010 02:30
On Fri 2010-07-30 09:05:23, James Morris wrote:
> On Thu, 29 Jul 2010, John Johansen wrote:
>
> > This is the seveth general posting of the newest version of the
> > AppArmor security module it has been rewritten to use the security_path
> > hooks instead of the previous vfs approach. The current implementation
> > is aimed at being as semantically close to previous versions of AppArmor
> > as possible while using the existing LSM infrastructure.
>
> Applied to
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>
> Please carry out any further development against the above tree.
>
> Note that I added the patch below to update AA against the latest
> version of path_truncate:

Ok, so now we have two name-based "security" modules. Can we at least
drop TOMOYO? That seems to have all apparmor disadvantages plus some
more...

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jan III Sobieski on 5 Aug 2010 06:00
Hi,

2010/8/5 Pavel Machek <pavel(a)ucw.cz>:
> On Fri 2010-07-30 09:05:23, James Morris wrote:
>> On Thu, 29 Jul 2010, John Johansen wrote:
>>
>> > This is the seveth general posting of the newest version of the
>> > AppArmor security module it has been rewritten to use the security_path
>> > hooks instead of the previous vfs approach. �The current implementation
>> > is aimed at being as semantically close to previous versions of AppArmor
>> > as possible while using the existing LSM infrastructure.
>>
>> Applied to
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>>
>> Please carry out any further development against the above tree.
>>
>> Note that I added the patch below to update AA against the latest
>> version of path_truncate:
>
> Ok, so now we have two name-based "security" modules. Can we at least
> drop TOMOYO? That seems to have all apparmor disadvantages plus some
> more...

Great idea! I suggest also to throw away the unnecessary filesystems.
Ext3 is great - who needs Ext4 or XFS?

--
Jan III Sobieski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Morris on 5 Aug 2010 06:30
On Thu, 5 Aug 2010, Pavel Machek wrote:

> > Note that I added the patch below to update AA against the latest
> > version of path_truncate:
>
> Ok, so now we have two name-based "security" modules. Can we at least
> drop TOMOYO? That seems to have all apparmor disadvantages plus some
> more...

No. The policy is that any security module which implements an access
control scheme and meets a well-defined security goal, and passes
technical review, may be merged.

aka, The Arjan Protocol:

http://kerneltrap.org/Linux/Documenting_Security_Module_Intent


--
James Morris
<jmorris(a)namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3
Prev: vhost-net: avoid flush under lock
Next: [PATCH] ecryptfs: dont call lookup_one_len to avoid NULL nameidata