Bug 442181 - AVC denial when redirecting X server output to a file
Summary: AVC denial when redirecting X server output to a file
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-12 14:37 UTC by Bill Crawford
Modified: 2008-05-06 21:12 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2008-05-06 21:12:04 UTC


Attachments (Terms of Use)

Description Bill Crawford 2008-04-12 14:37:37 UTC
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 20:00:14 UTC
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 14:16:08 UTC
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 14:16:38 UTC
I might just set the context and then *copy* the file ...

Comment 4 Daniel Walsh 2008-05-06 21:12:04 UTC
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.