[lkml]   [2007]   [Jun]   [21]   [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 Monday 18 June 2007 15:33, Stephen Smalley wrote:
    > On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
    > > There are two things:
    > >
    > > 1) relabeling (non-tranquility) is very problematic in general because
    > > revocation is hard (and non-solved in Linux). So you would have to
    > > address concerns about that.
    > I think we need to distinguish between relying on restorecond-like
    > mechanisms for the security of SELinux vs. relying on them for emulating
    > pathname-based security. The former would be a problem. The latter is
    > no worse than pathname-based security already, because pathname-based
    > security is inherently ambiguous and non-tranquil, and revocation isn't
    > addressed fully in AA either.

    Emulation using lazy relabeling introduces a window where the files have the
    wrong label. In those windows, the pathname based policy is being violated,
    and unintended side effects are suddenly possible. This includes granting of
    access to files that applications should no longer have access to according
    to the pathname based policy, which would be similar to what happens when a
    process keeps an open file handle right now. But it also includes denial of
    access to files that applications should have access to, and this might cause
    those applications to fail. So this is where relabeling from user space is
    much worse.

    The only way to get rid of the denial of service problem would be to make the
    rename and relabel an atomic operation. The time this can take is huge
    though, so that's not acceptable.

    Another, less catastrophic problem is that rename has always been relatively
    fast and inexpensive, and I'm sure plenty of applications rely on this
    performance characteristic. Making rename a very expensive operation in at
    least some cases (which are more than theoretical) would hurt those
    applications, and nothing much could be done about it.

    Adding better new-file mechanisms to SELinux probably is a good idea, and it
    would weaken the SELinux seurity model for all I can tell. It doesn't address
    the relabeling problem though.

    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-21 17:57    [W:0.023 / U:22.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site