[lkml]   [2007]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
    On Fri, 8 Jun 2007, Sean wrote:

    > On Sat, 9 Jun 2007 11:01:41 +0900
    > Tetsuo Handa <> wrote:
    > From the discussion so far, it seems that the different "model" that AA
    > is trying to implement, is to do in one step what SELinux does in two
    > steps; that is trying to combine labelling and enforcement into a
    > single step. If this is so, then why can't it just feed its automatic
    > labelling into SELinux enforcement code?
    >> I tried to give each file it's own label, but I couldn't do it.
    > That paper seems entirely focused on the automatic generation of policy,
    > and doesn't seem to help the discussion along. For instance, there may
    > be a way to implement AA on top of SELinux _without_ giving each and
    > every file its own label.
    >> There are many elements that forms too strong barrier between pathname and labels,
    >> such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
    >> So I gave up giving each file a label that can be used as an identifier,
    >> and took an approach to forbid unneeded mount operations, unneeded link operations,
    >> unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.
    > AA must have a function that decides the security rights for any given
    > path in order to make its enforcement decisions. It must surely be able
    > to deal with all those things you listed above (bind-mounts,hard links etc).
    > So why can't those decisions be turned into labels that are fed into SELinux
    > enforcement code?

    with AA hardlinks are effectivly different labels on the same file

    one of the big problems with SELinux is what label to put on new files
    (including temp files), the AA approach avoids this (frequent) problem
    entirely. In exchange AA picks up the (infrequent) problems of bind-mounts
    and hard-link creation. People have tried to equate these prolems to show
    that AA has just as many problems as SELinux, but you can run systems for
    decades without creating hard-links or bind-mounts

    also you seriously misunderstand the AA approach

    AA does NOT try to create a security policy for every file on the system.

    Instead AA policies are based on specific programs, and each policy states
    what files that program is allowed to access.

    if you are useing AA to secure all exposed services on a box you don't
    have to try to write a policy to describe what gcc is allowed to access
    (unless through policy you give one of your exposed services permission to
    run gcc, and even then I'm not sure if gcc would inherit restrictions
    from it's parent or just use it's own)

    the resulting policy is much easier to understand (and therefor check)
    becouse it is orders of magnatude smaller then any comprehensive SELinux

    the AA policy is also much easier to understand becouse you can look at it
    in pieces, understand that piece, and then forget it and move on to the
    next piece.

    for example, if you write a policy for apache that limits it's access to
    it's log files, install directories, and document root. then you write a
    policy for your log analysis tool to access it's libraries, report
    directories (under the apache document root) and the apache log files
    (read only), these two policies are independant, you don't have to think
    about one while creating the other (which you would have to do if you had
    to put one label on apache binaries, another on normal web documents, a
    third on the reports, a fourth on the log files, and a fifth on the
    binaries for the log analysis tool. and this is ignoring any overlap in

    AA also lets a sysadmin dip their toe in the water and just write a policy
    for Apache, not for anything else, then write a policy for firefox, then
    write a policy for their mail client, then for bittorrent, etc. there is
    no need or push to try and secure everything all at once, and no need to
    re-label files (and change any policies that used the old labels) when
    you discover a new interaction.

    David Lang
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-09 07:03    [W:0.025 / U:95.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site