linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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]

Message-ID: <Pine.LNX.4.64.0706241449300.12806@asgard.lang.hm>
Date:	Sun, 24 Jun 2007 14:57:43 -0700 (PDT)
From:	david@...g.hm
To:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
 pathname matching

On Sun, 24 Jun 2007, David Wagner wrote:

> Argument 3. AA isn't complete until it mediates network and IPC.
>
> Let me comment on these one-by-one.
>
> 3. This one I agree with.  If you want to sandbox network daemons that
> you're concerned might get hacked, then you really want your sandbox to
> mediate everything.  Right now the security provided by AA (if that's
> what you are using it for) will be limited by its incomplete mediation,
> since a knowledgeable motivated attacker who hacks your daemon may be
> able to use network or IPC to break out of the sandbox, depending upon
> the network and host configuration.  Filesystem mediation alone might be
> better than nothing, I suppose, if you're worried about script kiddies,
> but it's certainly not a basis for strong security claims.  The state of
> the art in sandboxing obviously requires complete mediation, and we've
> known that for a decade.

the issue I see is that AA may not have to implement any new in-kernel 
infrastructure to do this.

as recently as yesterday there have been discussions on the netfilter list 
about how to implement filter rules based on the application name (see the 
thread titled 'filter by application name') if this gets implemented 
independantly of AA then AA could provide a policy implementation layer 
over netfilter if desired (or sysadmins could just use their current 
favorite tool to control the network and AA to control the filesystem)

so holding up AA becouse this isn't implemented yet seems to be counter 
productive. people are working on this, and it is going to go in at some 
point independantly of AA, so why tie AA to it?

IPC is a very imprecise term. it includes lots of different ways for 
processes to communicate with each other. some forms of IPC are covered by 
AA today (unix sockets), others aren't. but each of the different methods 
is going to involve some difference in how it's controlled. if you want to 
talk IPC be specific about what IPC methods you are talking bout limiting.

David Lang
-
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/