[lkml]   [2007]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: AppArmor FAQ
    On Wed, April 18, 2007 14:15, Joshua Brindle wrote:

    >> Having said that, I feel a path based solution could have great
    >> potential
    >> if it could be used in conjunction with the object capability model,
    >> that
    >> I would consider a simple and practical alternative integrity model that
    >> does not require lables in an MLS maner, and that extends on the POLP
    >> concept in a way that would be largely more practical.
    > This would be combining two bad systems to get a worse one IMO.
    > Capability systems are inherently discretionary since propagated
    > capabilities must be removed at the discretion of the possessor of the
    > capabilities.

    That is assuming there is no caretaker or membrane implementation in the
    delegation chain, but I don't think we need to get into such details of
    object capabilities here. Point is there are ways to delegate revocable
    capabilities when using the OC model when required.

    > The argument that labels are not practical has yet to be shown but is
    > thrown around as if it is fact. Path based systems are inferior to label
    > based systems based if for no other reason than path based systems can't
    > control transient objects. With policy based type transition in SELinux
    > when my ssh client writes my agent socket to /tmp/ssh-xxxxxxxxxx SELinux
    > calculates a type transition based off my domain to label it
    > sysadm_ssh_t (or whatever is appropriate) whereas path based systems
    > can't possibly control access to these objects. The same goes for any
    > files written to home directories by user apps.

    I fully agree that path based security is inferior 'when used on its own'.

    >> That is, using 'thin' path based profiles would become very practical if
    >> all further authority can be communicated using handles in the same way
    >> that an open file handle can be communicated.
    > Once again, this creates a discretionary system that would not work
    > without modifying every single application that uses such authority

    It creates a discretionary enviroment that makes it much more natural
    for developers to create cooperating subsystems that are designed
    from an least authority perspective. And it creates the means to
    configure the system for such programs with a minimum amounth of
    profile information.

    Next to this, but a bit more complicated, path based security could in
    theory be used to make required authority explicitly designated. That is
    calling :

    cp ~/foo.txt ~/bar_directory/

    could ultimately explicitly transfer the user his authorities to both
    ~/foo.txt and ~/bar_directory/ to this instance of 'cp', but without
    transfering any other ambient authority. This example may be a bit
    out of the current range for AppArmor, but I feel it demonstrates that
    path based security may have potential added value in a least authority

    That is if Allice has authority to ~/, and ~/ contains ~/important.doc
    and allice has rw access to ~/important.doc, than ultimately invoking 'cp
    ~/foo.txt ~/bar_directory/' should not give the 'cp' instance the
    authority to read/write ~/important.doc, but invoking 'cp ~/foo.doc
    should. That is, if we want cp to work unmodified.

    > (and
    > trusting the code is bug free so that it does the right thing)

    I think the abouve shows that it actualy requeres 'less' trust in
    code if implemented right.

    > and gives
    > you an inflexible, decentralized, unmaintainable, unanalyzable policy
    > since it is distributed throughout code all over the system, you give
    > users no way to change the security characteristics of the system.

    I agree with the decentralized part, but in my view accomodating and
    allowing free and optionaly revocable delegation (you can always proxy
    anyway, so we know blocking it is misguided) makes for a much more
    flexible and esspecialy usable form of security.
    Systems designed according to POLA are definetely the most easy to
    do formal analysis of security properties on.

    I am not saying that path-based + OC would be 'better' than label based,
    I feel both would have their own level of granularity where they are
    usefull, and in some cases they could be complementary.

    I feel path based would be useless when possitioned purely as MAC, but
    when possitioned more as least authority bootstrap and designation
    mechanism complementary to least authority design ant usage of the OC model,
    I think path based may have some concrete use.

    sidenote: it is amusing to see that many OC advocates use many of your
    arguments (inflexible, unmaintainable, hard to analyze) to dismiss many
    label based MLS models as viable security models;-)


    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-04-18 16:09    [W:0.025 / U:70.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site