lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
    On Fri, 22 Jun 2007, Stephen Smalley wrote:

    > On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
    >> On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
    >>> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
    >>>> On 2007-06-21T15:42:28, James Morris <jmorris@namei.org> wrote:
    >>>>
    >>>
    >>>> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
    >>>> that's a missing feature, not broken by design.
    >>>
    >>> The incomplete mediation flows from the design, since the pathname-based
    >>> mediation doesn't generalize to cover all objects unlike label- or
    >>> attribute-based mediation. And the "use the natural abstraction for
    >>> each object type" approach likewise doesn't yield any general model or
    >>> anything that you can analyze systematically for data flow.
    >>>
    >> No the "incomplete" mediation does not flow from the design. We have
    >> deliberately focused on doing the necessary modifications for pathname
    >> based mediation. The IPC and network mediation are a wip.
    >
    > The fact that you have to go back to the drawing board for them is that
    > you didn't get the abstraction right in the first place.

    or it just means that the tool to regulat the network is different from
    the tool to regulate the filesystem.

    oh, by the way. that's how the rest of the *nix world works. firewall
    rules apply to networking, filesystem permissions and ACLs apply to the
    filesystem.

    this is like climing that the latest improvement to ipsec shouldn't go in
    becouse it down't allow you to handle things the same way that you handle
    temp files or a serial port.

    >> We have never claimed to be using pathname-based mediation IPC or networking.
    >> The "natural abstraction" approach does generize well enough and will
    >> be analyzable.
    >
    > I think we must have different understandings of the words "generalize"
    > and "analyzable". Look, if I want to be able to state properties about
    > data flow in the system for confidentiality or integrity goals (my
    > secret data can never leak to unauthorized entities, my critical data
    > can never be corrupted/tainted by unauthorized entities - directly or
    > indirectly), then I need to be able to have a common reference point for
    > my policy. When my policy is based on different abstractions
    > (pathnames, IP addresses, window ids, whatever) for different objects,
    > then I can no longer identify how data can flow throughout the system in
    > a system-wide way.

    if you are doing a system-wide analysis then you are correct.

    the AA approach is to start with the exposed items and limit the damage
    that can be done to you.

    sysadmins already think in terms of paths and what can access that path
    (directory permissions), AA extends this in a very natural way and doesn't
    require any special tools or extra steps for normal administration. As a
    result sysadmins are far more likely to use this then they are to touch
    anything that requires that they do a full system analysis before they
    start.

    another advantage is that since the policies are independant of each other
    it becomes very easy for software to include sample policies with the
    source.

    >>> Um, no. It might not be able to directly open files via that path, but
    >>> showing that it can never read or write your mail is a rather different
    >>> matter.
    >>>
    >> Actually it can be analyzed and shown. It is ugly to do and we
    >> currently don't have a tool capable of doing it, but it is possible.
    >
    > No, it isn't possible when using ambiguous and unstable identifiers for
    > the subjects and objects, nor when mediation is incomplete.

    it is possible to say that without assistance from an outside process the
    process cannot access the files containing your mail.

    if there is some other method of accessing the content no filesystem-level
    thing can know about it (for example, if another process is a pop server
    that requires no password). but I don't beleive that SELinux policies as
    distributed by any vendor would prevent this (yes, it would be possible
    for a tailored policy to prevent it, but if the policy is so complex that
    only distro staff should touch it that doesn't matter in real life)

    David Lang
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-22 20:37    [W:2.438 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site