[apparmor] Handling meta-read permissions
john.johansen at canonical.com
Wed Aug 11 09:54:43 BST 2010
On 08/10/2010 01:16 AM, Jamie Strandboge wrote:
> On Mon, 2010-08-09 at 20:24 -0400, John Johansen wrote:
>> On 08/09/2010 04:55 PM, Jamie Strandboge wrote:
>> Basically I agree with you that this is the way to go and that the
>> meta-r nometa-r is UGLY. Actually I was hoping for a better proposal on
>> what to name extend permissions. I want to make them available at
>> the rule level, but with the common case of r, w etc expanding out to
>> the extended list internally.
> Yeah, meta-r and nometa-r is totally icky and I am *not* advocating it
> for the profile language. ;)
> I agree that the extend permissions should be on the rule level and the
> 'r' and 'w' should extend out internally. Perhaps thinking more broadly
> would shed some light on this. Are there other extend permissions we may
> want sometime in the future (delete, create, chmod, others)?
meta-read, meta-write, create, delete, chmod, chown, trunc (if we want
though I haven't seen the need to separate this one out), and I would
like sticky, setuid, setguid, and possibly separate ones for setting
different extended attributes (though this last set is problematic
at the moment.
There is also the whole extended conditional abilities that can be
leveraged. Conditional permissions based on who owns the file
(not just being the owner), if the file is actually a specific device
> What about expanding out farther and thinking about all the potential
> policy language changes such as the capability additions (chown, ptrace,
> chroot and setuid) and 'owner'. Are there others? Thinking about
> everything we want to support may show one method is better over
yes, and some of that has already been raised in another email (look
back to July 29 - Handling expanded permissions). Basically there
is a lot of extended permissions and capabilities we want to support,
and that we currently don't have a way of expressing.
Some of them can be path oriented like meta-read, meta-write, etc and
others like setuid are going to need new rules, and we will have to
deal with how that interacts with current behavior.
Before any of this can happen though there needs to be some under the
hood cleanups. So I haven't been pushing on it, currently I look
at it as planning the future so the emails will come as I have time,
motivation and or inspiration.
A lot of this is actually already in the kernel module
and it just needs an updated interface and testing beyond the current
restricted set that is being mapped in.
User space is a whole different story. The dfa backend needs some
serious reworking. I've started it, have a plan, etc and the patches
will start slowly leaking out.
Basically we need to
- separate regex tree, and dfa, reworking the meaning of state
- rework how the dfa is calculating accept states, and make the accept
state sets independent from the dfa (dfa doesn't need apparmor
- cleanup the regex to be able to take in and properly handle the
expanded flexible permission set (again it shouldn't have specific
knowledge so the routines can reused in different ways).
- and while we are at it add native aare parsing, and quiet possibly
native network as well.
- And while we are at it the dfa regex.y will get split into 4 different
files, separating the different logical bits making the whole thing
more manageable, also helping to ensure that things don't get
intertwined in ways they shouldn't.
- Add dfa merge and set operations
- update the front end parsing to be able to bring in the rules
- update the mid layers to handle the new rule and permission types
(early rule elimination etc).
- Rework some of the internal structures to make this more sane.
- currently rule merging is brittle, and breaks with each new permission
or rule type added
- And this hasn't even touched on the tools
All those are necessary and of course that doesn't cover my pet cleanup lists of
- improving regex tree normalization and factoring
- cleanup minimization, reworking the intitial partition set and how
repartitioning finds what needs to be split.
This will lead to smaller dfas (as or initial partition set is
actually too broad, and should be faster if partition splitting is
- hash node sets for faster dfa creation when there are large sets
- stabilize dfa creation by using static numbering to determine node
set ordering instead of using memory pointers
- improve table compression
- update table compression format
- moving away from glibc data abstractions
- separating the paser into a compiler and loader, with the
apparmor_parser being just a driver for them.
- and a million other little things.
The actual work item list would be even larger, basically we have hit
a point where to go forward a lot of cruft needs to be cleaned up and
reworked, as adding new things is becoming very difficult. And also
requires much duplication of work.
If I update the parser, that addition doesn't propagate into the tools,
and they need to have their "parsing" updated etc. And hence the tools
are in a pretty bad shape atm.
My focus for all too long has been the kernel, now that that, is sort of
in a livable state, I need to turn some attention to cleaning up the
userspace, so this can become more than just discussion.
More information about the AppArmor