lkml.org 
[lkml]   [2006]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview
    * Andi Kleen (ak@suse.de) wrote:
    > > > 3/ Is AppArmour's approach of using d_path to get a filename from a
    > > > dentry valid and acceptable?
    >
    > I suppose it needs at least to use the proper vfsmounts instead of
    > walking the global list. That would need better hooks. And probably
    > some caching (trying to match dentries directly?) to get better performance.

    Yes, walking the list is ugly. I think you'd wind up having to pin
    those dentries in memory (or do what DTE tried with a shadow tree).

    > Regarding the basic use of pathnames I don't see a big problem. After
    > all the kernel uses dentries for everything too and dentries are
    > just a special form of path name too.

    The biggest issue with pathnames is they are non-determinstic,
    esp. when recreated after the fact using d_path. So the pathname as
    object argument makes sense when talking about objects (vfsmont/dentry),
    not strings (d_path). Also, when mediating solely on pathname it's very
    difficult to reason about the contents of the inode that's pointed to by
    the pathname. This means that policy which allows a subject the ability
    to write to the object whose handle is /tmp/my_unimportant_tmpfile may be
    a security problem if somebody in the system was tricked into a simple 'ln
    /etc/shadow /tmp/my_unimportant_tmpfile.' In this case it's surprising
    that the same inode can have different permissions (esp. given traditional
    DAC uid/gid and mode bits are kept in inode) depending upon path taken.

    The AA stance is that the policy will protect the confined process from
    doing such namespace manipulations eliminating the possibiilty of the
    confined process and giving itself a mechanism to privilege escalation.
    This is reasonable with the caveat that the channels available to the
    confined process to collude with (or coerce) an unconfined process are
    still pretty high-bandwidth. One could argue that having unconfined
    processes is ill-advised. SELinux targeted policy has the same basic
    issue (channel richness notwithstanding), which is why I'd expect truely
    security sensitive environments would use a strict policy.

    I guess it's worth noting the AA atack is stopped by SELinux, while the
    opposite is also true. A 'cp /etc/shadow /tmp; mv /tmp/shadow /etc' done
    by an unconfined process doesn't effect AA, while it kills the type
    label on /etc/shadow and could be an effective policy breach. In each
    case somewhat subtle (i.e. not explicit relabel or policy change) can
    have holes.

    thanks,
    -chris
    -
    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: 2006-04-27 12:20    [W:3.762 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site