Bug 442181 - AVC denial when redirecting X server output to a file
AVC denial when redirecting X server output to a file
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-12 10:37 EDT by Bill Crawford
Modified: 2008-05-06 17:12 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 17:12:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Crawford 2008-04-12 10:37:37 EDT
Description of problem:
Apr 12 13:01:43 pikachu kernel: type=1400 audit(1208001703.612:9): avc:  denied
 { write } for  pid=8648 comm="X" path="/home/bill/X.log" dev=dm-9 ino=10092547
scontext=unconfined_u:unconfined_r:xdm_xserver_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.3.1-33.fc9.noarch

How reproducible:
Redirect X server output to a file when running as (unconfined, in theory) user
as follows: mv -f X.log X.log.old ; startx -- -accessx >&X.log

Steps to Reproduce:
1. Run X redirected to file as above
2. Wait for it to print something
3. See denial
  
Actual results:
AVC denial (am in permissive mode currently, as I've encountered a lot of these
warnings).

Expected results:
Since I'm allowed to see the server's output I should be able to write it to a
file I own.

Additional info:
Comment 1 Daniel Walsh 2008-05-02 16:00:14 EDT
This is a know issue which we don't have a good solution to, until we update the
kernel with open perms.

You might be able to get this to work by executing 

mv -f X.log X.log.old ; startx -- -accessx | cat >&X.log

Or if you change the context of x.log to xserver_log_t

touch X.log
chcon -t xserver_log_t X.log

Comment 2 Bill Crawford 2008-05-03 10:16:08 EDT
Yeah, I realise it's a bit of ... can of worms. The latter solution (changing
the context) looks good. If only there were some way of having that done
automatically ....

I take this is but one example of the clash between the "do what you need to do
and drop privilages" paradigm and the SELinux one ;o)
Comment 3 Bill Crawford 2008-05-03 10:16:38 EDT
I might just set the context and then *copy* the file ...
Comment 4 Daniel Walsh 2008-05-06 17:12:04 EDT
There is a new feature coming where the kernel separates out the access of open
versus just read/write.  Currently we can not differentiate one process handing
an open file descriptor for read/write from a process actually opening a file
for read/write.

So once we have this feature we can add boolean support to allow domains to
read/write files in users homedir but never open them.  This would allow your
example where bash is actually opening the file as unconfined_t and then handing
the open filedescriptor to xserver_t.

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