Prev: 'struct uart_port' has no member named 'info
Next: percpu,module: implement and use is_kernel/module_percpu_address()
From: Andreas Gruenbacher on 10 Mar 2010 06:30
On Wednesday 03 March 2010 15:09:41 Christoph Hellwig wrote:
> On Tue, Mar 02, 2010 at 07:01:05PM +1100, James Morris wrote:
> > I noticed that there are differences in the behavior of listxattr(2) for
> > xattrs in the trusted namespace.
> >
> > Some filesystems, such as ext[234], require CAP_SYS_ADMIN for this, i.e.
> > trusted xattr names are hidden from unprivileged users.
> >
> > I audited the kernel for users of the trusted xattr namespace, and found
> > the following filesystems not checking for CAP_SYS_ADMIN:
> >
> > - jffs2
> > - ocfs2
> > - btrfs
> > - xfs
> >
> > I've created patches for jffs2 (tested) and ocfs2 (not tested) to add the
> > check -- see following emails. btrfs and xfs have custom listxattr
> > operations and will need a bit more work to fix.
>
> I think the behaviour of the above filesystems is correct. There is no
> requirement for privilegues to see the existence of these attributes.
> We also don't hide entries that aren't readable from readdir output.

The original idea was that regular processes will never have access to
trusted.* attributes anyway, and so there is little point in listing such
attributes in the first place.

This is different from user.* attributes which a particular process may or may
not have access to depending on file permissions. Checking those permissions
in listxattr() would have significant overheads, and race with permission
changes, possibly leading to weird results. (In contrast, processes don't
usually listxattr() with privileges and then getxattr() without privileges, or
vice versa.)

Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andreas Gruenbacher on 10 Mar 2010 07:00
On Wednesday 03 March 2010 14:02:58 Stephen Smalley wrote:
> Should it be using has_capability_noaudit() rather than capable() so
> that merely calling listxattr() on a file that happens to have trusted
> xattrs does not set PF_SUPERPRIV on the task and does not trigger an
> audit message?

Yes, makes sense. A version of has_capability_noaudit() without an explicit
task parameter, like security_capable(), would be better still.

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: 'struct uart_port' has no member named 'info
Next: percpu,module: implement and use is_kernel/module_percpu_address()