lkml.org 
[lkml]   [2006]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview
    From
    Date
    On Thu, 2006-04-27 at 03:17 -0700, Chris Wright wrote:
    > 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.

    Even in the absence of any "unconfined" processes, the potential for
    collusion among multiple "confined" processes (via coordinated attack)
    shouldn't be overlooked. Thus, the base mechanism needs to be resilient
    in the face of such collusion.

    > 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.

    Not sure about the example here, as the type in that case would actually
    be lost upon the cp by the unconfined process to the /tmp location, in
    which case you have an issue for both AA and SELinux - the data has
    become accessible under a different name and label which may now be
    accessible beyond the original intent. If you had used appropriate
    options to cp to preserve the attribute, then it would have preserved
    the type throughout the transaction. Of course, the real problem here
    is that you have an unconfined process copying the data at all, at which
    point you have no real guarantees about it, and the loss in label is the
    least of your worries.

    --
    Stephen Smalley
    National Security Agency

    -
    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 18:01    [W:4.455 / U:0.288 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site