* security_path hooks for xattr
@ 2012-01-26 12:45 Miklos Szeredi
[not found] ` <87fwf2y6mw.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Miklos Szeredi @ 2012-01-26 12:45 UTC (permalink / raw)
To: john.johansen; +Cc: apparmor, linux-fsdevel, linux-kernel, draht
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?
Thanks,
Miklos
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <87fwf2y6mw.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>]
* Re: security_path hooks for xattr 2012-01-26 12:45 security_path hooks for xattr Miklos Szeredi @ 2012-01-26 16:04 ` Casey Schaufler 0 siblings, 0 replies; 5+ messages in thread From: Casey Schaufler @ 2012-01-26 16:04 UTC (permalink / raw) To: Miklos Szeredi Cc: apparmor-nLRlyDuq1AZFpShjVBNYrg, linux-kernel-u79uwXL29TY76Z2rM5mHXA, LSM, draht-IBi9RG/b67k, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA On 1/26/2012 4: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? Please post proposed patches to linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > Thanks, > Miklos > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- AppArmor mailing list AppArmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: security_path hooks for xattr @ 2012-01-26 16:04 ` Casey Schaufler 0 siblings, 0 replies; 5+ messages in thread From: Casey Schaufler @ 2012-01-26 16:04 UTC (permalink / raw) To: Miklos Szeredi Cc: john.johansen, apparmor, linux-fsdevel, linux-kernel, draht, LSM On 1/26/2012 4: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? Please post proposed patches to linux-security-module@vger.kernel.org > > Thanks, > Miklos > -- > 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/ > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: security_path hooks for xattr 2012-01-26 12:45 security_path hooks for xattr Miklos Szeredi @ 2012-01-26 21:57 ` John Johansen 0 siblings, 0 replies; 5+ messages in thread From: John Johansen @ 2012-01-26 21:57 UTC (permalink / raw) To: Miklos Szeredi Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, apparmor-nLRlyDuq1AZFpShjVBNYrg, linux-kernel-u79uwXL29TY76Z2rM5mHXA, draht-IBi9RG/b67k 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: security_path hooks for xattr @ 2012-01-26 21:57 ` John Johansen 0 siblings, 0 replies; 5+ messages in thread From: John Johansen @ 2012-01-26 21:57 UTC (permalink / raw) To: Miklos Szeredi; +Cc: apparmor, linux-fsdevel, linux-kernel, draht 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-26 21:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2012-01-26 21:57 ` John Johansen
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.