linux-kernel - Re: [AppArmor 00/41] AppArmor security module overview

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Apr 2007 06:33:07 -0400
From:	Shaya Potter <spotter@...columbia.edu>
To:	jjohansen@...e.de
CC:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [AppArmor 00/41] AppArmor security module overview

jjohansen@...e.de wrote:
> This post contains patches to include the AppArmor application security
> framework, with request for inclusion.

question in general, these seems like a fairly invasive series of 
patches.  back when I first started graduate school, I prototyped a 
relatively simple stackable file system on 2.4 that seems to be able to 
do a lot of what app armor does (or at least seems to be easily 
extensible to o everything app armor does) from an fs perspective, 
without having to modify the kernel at all, why not use that approach?

What I did back then was I took Erez Zadok's fist, created his base0fs, 
which basically does nothing, just passes everything directly down.  I 
viewed it as a null stackable fs.  I then modified it to

a) contain a set of rules (be able to add, delete, modify them)

b) fs's private lookup() determines if a dentry matches a rule and tags
it (stored in dentry private data, but inode can be used as well)

c) fs's private permission() checks the rule data stored in private data 
to determine if the generic_permission should be even called.

what I didn't do is mmap or hard link, but those are additional checks 
one can do in those specific f_ops.

Basically, why force the VFS to change, when one can create an 
apparmorfs that stacks on top of whatever fs you want to use app armor 
rules with, create a namespace containing that new stacked fs only (to 
contain processes within the stacked fs).

This approach doesn't suffer from the normal stackable file system 
"issue" since  there should be no complex what I'll call "cache 
coherency" issues due to the stackable "directory entry" namespace being 
the same exact as the underlying namespace and it passing down page 
cache operations directly to the lower fs.  So one could stack on top of 
a file system one is using for both apparmor protected and unprotected 
processes.

I could imagine there might be an issue w/ how one deals with special 
file systems (ala proc and others).  But the way we approached this in 
general, is that this is an aspect of containers. namely, each protected 
area is a container itself, and hence has its own private virtualized 
proc....

my code was mostly prototype level (As well as only for 2.4), but it 
would seem to very easily to duplicate in a production level quailty for 
2.6.

anyways, just a thought
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/