Bug 171846 - setxattr doesn't appear to work
setxattr doesn't appear to work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: James Morris
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-26 19:07 EDT by Nalin Dahyabhai
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-20 15:22:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Extend selinuxfs context interface to allow canonicalization of contexts (2.83 KB, patch)
2005-10-31 15:28 EST, Stephen Smalley
no flags Details | Diff

  None (edit)
Description Nalin Dahyabhai 2005-10-26 19:07:41 EDT
Description of problem:
The setxattr() syscall returns 0, but doesn't seem to do anything.

Version-Release number of selected component (if applicable):
2.6.13-1.1627_FC5smp

How reproducible:
Always

Steps to Reproduce:
1. Run "chcon -t shlib_t /lib/security/pam_xauth.so" (or use "lib_t" if its type
is already "shlib_t".
2. Use "ls -lZ" to read the context of the file.
  
Actual results:
The file context doesn't change.
Running under strace shows this:
setxattr("/lib/security/pam_xauth.so", "security.selinux",
"system_u:object_r:shlib_t:s0", 29, 0) = 0
so it looks like it's a kernel bug.

Expected results:
It should change.

Additional info:
This is on an ext3 filesystem.
Comment 1 Daniel Walsh 2005-10-27 08:29:36 EDT
Seems to be some new feature of the kernel.

On targeted systems shlib_t and lib_t are typealiased in policy.

But there seems to be a new behavior.

ls -lZ log
-rw-r--r--  root     root     system_u:object_r:usr_t          log
 chcon -t shlib_t log
 ls -lZ log
-rw-r--r--  root     root     system_u:object_r:lib_t          log
chcon -t usr_t log
ls -lZ log
-rw-r--r--  root     root     system_u:object_r:usr_t          log

Problem is if you do multiple restorecon over /lib it will always report things
as wrong even when it attempts to clean it up.
Comment 2 Stephen Smalley 2005-10-27 08:35:37 EDT
This is a result of James' patch to allow SELinux to canonicalize the value
returned by getxattr to the incore security context of the inode rather than the
on-disk xattr.  This was originally requested to support MCS (so that the
contexts would get the :s0 suffix even for files that hadn't been relabeled for
MCS, so that a getxattr/setxattr sequence would always work).  It was also
desired to ensure consistency between what userspace sees and what SELinux sees
internally, as that has been a problem in the past (e.g. unlabeled_t vs on-disk
xattr).
Internally, SELinux always caonicalizes type aliases to the primary type name.

Options are:
- Alter file_contexts for targeted policy to use the primary name,
- Alter restorecon and setfiles to check for aliases (requires a sepol interface
to compare contexts for equivalency).
Comment 3 Stephen Smalley 2005-10-27 11:32:49 EDT
Note:  I'm looking into the latter option, but doing it in matchpathcon instead
(i.e. call sepol to canonicalize the context returned by matchpathcon, so that
setfiles, restorecon, et al will end up with canonical contexts from both
matchpathcon and getfilecon and thus they will match).
Comment 4 Stephen Smalley 2005-10-27 12:06:02 EDT
Alternative approach would be to add an interface to selinuxfs by which the
SELinux module could provide the canonical context string for a given context
string based on the currently loaded policy, and change matchpathcon to use that
interface.  Advantage would be that the selinuxfs interface would ensure that we
are dealing with the same policy as the kernel, avoids the need to allow all
users of matchpathcon to directly read the kernel binary policy file, and avoids
the overhead of parsing the kernel binary policy file on matchpathcon_init.  The
disadvantage is primarily that it requires a kernel patch, and thus will take
longer to get upstream than a change to libsepol  Thoughts?
Comment 5 Daniel Walsh 2005-10-27 12:20:52 EDT
chcon would need to warn about this situation, then.

chcon -t shlib_t /lib/libselinux.so.1
Warning: shlib_t is an alias of lib_t...
Comment 6 Stephen Smalley 2005-10-28 08:35:55 EDT
I'd recommend creating a patch to selinuxfs to extend the semantics of
/selinux/context such that a write/read sequence will validate the provided
context on the write (as is already done) and then return the canonical context
on the read (a transaction op, like the /selinux/create interface).  That won't
break existing users of security_check_context(3), but will allow us to add a
security_canonicalize_context() function to libselinux that uses the same
underlying selinuxfs interface.  Then matchpathcon_init can use this interface
rather than security_check_context() to both validate and canonicalize the
context.  That will avoid spurious warnings from setfiles and restorecon and
ensure that the canonical name is always applied by them (and rpm and anything
else using matchpathcon).  chcon can also use the new interface to check whether
the canonical context differs from the supplied one and can warn in that case if
you like.

I prefer this approach to the experimental patches I posted on selinux list for
libsepol and libselinux for the reasons stated in comment #4, i.e. it ensures
that we are dealing with the same policy as the kernel, avoids the need to allow
all users of matchpathcon to read the kernel binary policy file, and avoids the
overhead of parsing the kernel binary policy file on matchpathcon_init.

If, due to time pressure, we need a short term workaround, we could go with the
libsepol patch until the kernel change is upstreamed, but I think that the
kernel patch is the right long term approach.  James?
Comment 7 Stephen Smalley 2005-10-28 09:58:12 EDT
Note btw that to canonicalize the context, all you have to do is go through a
security_context_to_sid();
security_sid_to_context();
sequence.  The latter will always yield the canonical form.  The former is
already done by sel_write_context() to validate the context, so one would just
have to convert it over to using the transaction ops, perform the
security_sid_to_context call to get the canonical form, and copy that into the
buffer, similar to sel_write_create.
Comment 8 Stephen Smalley 2005-10-31 15:28:08 EST
Created attachment 120588 [details]
Extend selinuxfs context interface to allow canonicalization of contexts

This patch extends the selinuxfs context interface to allow canonicalization of
contexts.
Patch is by a colleague.
Comment 9 Stephen Smalley 2005-11-04 12:21:51 EST
Ping.  Do we want to proceed with this kernel patch to enable userspace to
obtain the canonical form of a context?  
Comment 10 James Morris 2005-11-04 13:12:36 EST
Yep, I think so.
Comment 11 Stephen Smalley 2005-11-18 07:23:27 EST
Kernel patch was upstreamed and is in the rawhide kernel, and corresponding
patches to libselinux (matchpathcon) and setfiles were likewise committed and
included in rawhide, so restorecon, setfiles, and other users of matchpathcon
should no longer warn about type mismatches in lib_t/shlib_t and other type
alias cases in the targeted policy.

chcon could be patched to use security_canonicalize_context() to obtain the
canonical form of the user-supplied context in order to let the user know when
it is being canonicalized.
Comment 12 Robert Scheck 2005-11-20 14:05:44 EST
Linux kernel 2.6.14-1.1697_FC5 includes the patch and solves the problem for me.

Note You need to log in before you can comment on or make changes to this bug.