All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Johansen <john.johansen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
To: Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	draht-IBi9RG/b67k@public.gmane.org
Subject: Re: security_path hooks for xattr
Date: Thu, 26 Jan 2012 13:57:20 -0800	[thread overview]
Message-ID: <4F21CC40.3030207@canonical.com> (raw)
In-Reply-To: <87fwf2y6mw.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>

On 01/26/2012 04:45 AM, Miklos Szeredi wrote:
> Forwarding from an internal bug report:
> 
>    "AppArmor does not mediate the xattr system calls for confined processes.
> 
>    As a consequence, a confined process can cross the confinement privilege
>    boundary by reading or writing to extended attributes that the confined
>    task should not have access to. The restrictions for security and user
>    attributes read and write still apply according to DAC; however, this
>    does not comply with the claim of AppArmor to mediate fipe
>    operations. The use of extended attributes is very flexible, so that the
>    effect of a missing mediation can lead to false assumptions in
>    subsequent policy decisions (eCryptfs)."
> 
> AFAIU this boils down to missing security hooks in *xattr().
> 
> Would it be possible to add these hooks?
> 
right, this is something we lost when we moved to the security_path hooks and
while we have spent some time looking at the problem, we haven't addressed it
yet.  

New hooks would certainly be the easiest solution. I looked at it back when
I initially did the port, and considered proposing new hooks at the time, but
for various reasons it was decided to separate that from the main apparmor
submission, and I haven't had a chance to revisit this since.


-- 
AppArmor mailing list
AppArmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

WARNING: multiple messages have this Message-ID (diff)
From: John Johansen <john.johansen@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: apparmor@lists.ubuntu.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, draht@suse.com
Subject: Re: security_path hooks for xattr
Date: Thu, 26 Jan 2012 13:57:20 -0800	[thread overview]
Message-ID: <4F21CC40.3030207@canonical.com> (raw)
In-Reply-To: <87fwf2y6mw.fsf@tucsk.pomaz.szeredi.hu>

On 01/26/2012 04:45 AM, Miklos Szeredi wrote:
> Forwarding from an internal bug report:
> 
>    "AppArmor does not mediate the xattr system calls for confined processes.
> 
>    As a consequence, a confined process can cross the confinement privilege
>    boundary by reading or writing to extended attributes that the confined
>    task should not have access to. The restrictions for security and user
>    attributes read and write still apply according to DAC; however, this
>    does not comply with the claim of AppArmor to mediate fipe
>    operations. The use of extended attributes is very flexible, so that the
>    effect of a missing mediation can lead to false assumptions in
>    subsequent policy decisions (eCryptfs)."
> 
> AFAIU this boils down to missing security hooks in *xattr().
> 
> Would it be possible to add these hooks?
> 
right, this is something we lost when we moved to the security_path hooks and
while we have spent some time looking at the problem, we haven't addressed it
yet.  

New hooks would certainly be the easiest solution. I looked at it back when
I initially did the port, and considered proposing new hooks at the time, but
for various reasons it was decided to separate that from the main apparmor
submission, and I haven't had a chance to revisit this since.


  parent reply	other threads:[~2012-01-26 21:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 12:45 security_path hooks for xattr Miklos Szeredi
     [not found] ` <87fwf2y6mw.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>
2012-01-26 16:04   ` Casey Schaufler
2012-01-26 16:04     ` Casey Schaufler
2012-01-26 21:57   ` John Johansen [this message]
2012-01-26 21:57     ` John Johansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F21CC40.3030207@canonical.com \
    --to=john.johansen-z7wlfzj8ewms+fvcfc7uqw@public.gmane.org \
    --cc=apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org \
    --cc=draht-IBi9RG/b67k@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.