* security_path hooks for xattr
@ 2012-01-26 12:45 Miklos Szeredi
2012-01-26 16:04 ` Casey Schaufler
2012-01-26 21:57 ` John Johansen
0 siblings, 2 replies; 3+ 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] 3+ messages in thread
* 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
2012-01-26 21:57 ` John Johansen
1 sibling, 0 replies; 3+ 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] 3+ messages in thread
* 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
@ 2012-01-26 21:57 ` John Johansen
1 sibling, 0 replies; 3+ 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] 3+ messages in thread
end of thread, other threads:[~2012-01-26 21:57 UTC | newest]
Thread overview: 3+ 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
2012-01-26 16:04 ` Casey Schaufler
2012-01-26 21:57 ` John Johansen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).