[Apparmor-dev] 2.6.29 update

[John Johansen]

Mario Fetka wrote:
> Ping
> 
Pong,

Sorry, I should have updated sooner.  Obviously it hasn't been posted
yet, but it is coming, sometime this week.  I am actually working on it
full time now instead of fitting in a few hours here and there so, the
work will progress much quicker.

The delay has been a combination of several things,
- last I posted I was actually traveling and my net access turned
  out to be non-existent for a few days.  And then was a week at UDS,
  followed by catching up from traveling/UDS
- as always it has taking longer than expected
- a few items got dropped off my to do list, that were needed which
  helped cause the under estimation
- I have ended up reworking some of the structures a bit because of
  above missed items.  And in the sid case actually adding the base sid
  support, which I had planned originally to add after pushing out.

  To explain the change here was that under the newer kernels the
  old fork tracking method of fork tracking isn't possible (it was brain
  dead anyways so this is for the best), and it needed to be replaced.

  The replacement is that it is now handled at the exec level, and the
  null-complain profile is replaced by unique profile per complain exec.
  Anyways this is just one of the important items I managed to miss.

  The sid part comes in because I was going to originally just do
  null-####-<parent profile> where #### was just some unique number.
  However I was looking at some stuff that will require a sid and
  realized that the sid is some unique # and doing a very basic support
  of it now is a little more work than just a special case unique
  numbering of profiles, but it will also save work in the future.

  If your curious what a sid is, it a security identifier, basically
  a unique id that can be used to lookup the profile, and they will be
  necessary for some of the ipc mediation in the future.

- bugs, bugs, bugs.  There have been several reference counting bugs and
  other problems leading to early oops.  I just fixed another one this
  morning.  I have been going through and review each line of code
  dealing with policy and context.


So just to be clear, what will drop this week won't be bug free but the
goal is you will be able to load policy and actually use it.  The tools
beyond the parser will not work with it, this is mostly due to the fork
tracking changes that were necessary, but since I had to break the tools
I took the opportunity to make a few other changes as well (again a case
of more work now for less later).

The feature set isn't pure 2.3 either, the change to the path_permission
hooks has mandated some changes.  And at the same time I took the
opportunity to roll in some of the 3.0 work (again a case of more work
now to save in the future).  This has been mostly done around the
structure of profiles, contexts, and permissions.  These additions came
from my desire to, not have to go back and rework things again for those
features in the future.

So for those who are curious what these features are:
  permission
  - have been separated from the dfa, (with current dfa mapping to
    internal permission set).  Its a cleanup needed for the future
    and also upstreaming
  - the c (create) permission has been added but it is not directly
    accessible currently.  The semantics of this change will be
    posted later, but it won't require changes to policy and it
    will allow for tighter control of creation when desired.
    Its main uses will only become available when better conditionals
    hit.
  - updated and more generic x transition perms
    - more named transitions allowed
    - the ability to do pux,
    - the ability to specify an in chain of options in preference order
       ie.
        /foo px -> profile1 profile2 profile3 inherit
 policy
 - namespaces are fully fleshed out.
 - pattern matching profile names.
   eg.  /bin/** { }
 - change_profile on exec command
 - children profiles are folded back under the parent profile instead
   of being flat in the namespace.
   This speeds up searches, but mainline done for replace and remove
   characteristics.
- user defined profiles (ie. there is the concept of system profiles and
  user profiles, and a task can be confined by both at the same time).
  This isn't fully fleshed out in that more auditing changes are needed,
  to keep user profiles from flooding the system logs, etc.
  This was all about not wanting to have to redo the context work later.
- better auditing control.  The whole auditing code was revised and
  cleaned up/broken out.  And new control options and modes were added
  - modes - normal, quiet, noquiet, all
  - kill flag - the ability for the audit system to kill processes when
    there is something denied

And miscellaneous other changes that I can't think of off the top of my
head.  The real pain is that almost none these features will be
accessible at first.  The kernel structures and support are there but
the user space support isn't, meaning these features, are going to be
untested.  The important part being the code is designed to support them
and I won't have to rework the core to enable them.

john