Bug 187712 - gthumb is "denied" access to digitial camera attached via USB while SELinux is enabled.
gthumb is "denied" access to digitial camera attached via USB while SELinux i...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-02 23:05 EDT by dave
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-28 16:03:33 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)
audit.log trace while plugging in camera. (2.91 KB, text/plain)
2006-04-02 23:05 EDT, dave
no flags Details
audit.log trace when digital camera is turned on. (2.44 KB, text/plain)
2006-04-26 18:54 EDT, Dimi Paun
no flags Details
audit.log trace when digital camera is turned on (try 2) (2.44 KB, text/plain)
2006-04-28 00:18 EDT, Dimi Paun
no flags Details

  None (edit)
Description dave 2006-04-02 23:05:10 EDT
Description of problem:

gthumb is "denied" access to digitial camera attached via USB while SELinux
Enforced mode. Switching to Permissive mode works well i have attached a output
from /var/log/audit/audit.log while plugging in the camera when in permissive
mode.  

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

rpm -qa | grep selinux:

selinux-policy-targeted-2.2.25-2.fc5
libselinux-devel-1.30-1.fc5
libselinux-1.30-1.fc5
libselinux-python-1.30-1.fc5
selinux-policy-2.2.25-2.fc5

How reproducible:

Very


Steps to Reproduce:
1. switch to permissive mode (enforcing mode) will not work 
2. tail -f /var/log/audit/audit.log
3. plug in camera.
  
Actual results:

See attached log file.

Expected results:

I would expect it to work even with SELinux Enforced?

Additional info:

None.
Comment 1 dave 2006-04-02 23:05:11 EDT
Created attachment 127221 [details]
audit.log trace while plugging in camera.
Comment 2 Daniel Walsh 2006-04-03 11:26:31 EDT
Fixed in selinux-policy-2.2.29-2.fc5
Comment 3 Dimi Paun 2006-04-24 23:54:22 EDT
This still doesn't work for me:

[root@dimi ~]# rpm -q selinux-policy
selinux-policy-2.2.29-3.fc5

When I turn on my Cannon SD400, I get this:

[root@dimi ~]# tail -f /var/log/audit/audit.log
[...snip existing stuff, and wait for events generated by camera...]
type=AVC msg=audit(1145936987.724:181): avc:  denied  { read } for  pid=2746
comm="cat" name="console.lock" dev=dm-0 ino=4178410
scontext=system_u:system_r:hald_t tcontext=system_u:object_r:init_var_run_t
tclass=file
type=SYSCALL msg=audit(1145936987.724:181): arch=40000003 syscall=5 success=yes
exit=3 a0=bf95c8e9 a1=8000 a2=0 a3=8000 items=1 pid=2746 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="cat" exe="/bin/cat"
type=CWD msg=audit(1145936987.724:181):  cwd="/usr/libexec"
type=PATH msg=audit(1145936987.724:181): item=0
name="/var/run/console/console.lock" flags=101  inode=4178410 dev=fd:00
mode=0100600 ouid=0 ogid=500 rdev=00:00
type=AVC msg=audit(1145936987.724:182): avc:  denied  { getattr } for  pid=2746
comm="cat" name="console.lock" dev=dm-0 ino=4178410
scontext=system_u:system_r:hald_t tcontext=system_u:object_r:init_var_run_t
tclass=file
type=SYSCALL msg=audit(1145936987.724:182): arch=40000003 syscall=197
success=yes exit=0 a0=3 a1=bf95c54c a2=ac8ff4 a3=804d7e0 items=0 pid=2746
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="cat" exe="/bin/cat"
type=AVC_PATH msg=audit(1145936987.724:182):  path="/var/run/console/console.lock"
type=AVC msg=audit(1145936987.728:183): avc:  denied  { chown } for  pid=2749
comm="chown" capability=0 scontext=system_u:system_r:hald_t
tcontext=system_u:system_r:hald_t tclass=capability
type=SYSCALL msg=audit(1145936987.728:183): arch=40000003 syscall=212
success=yes exit=0 a0=95fbd60 a1=1f4 a2=ffffffff a3=0 items=1 pid=2749
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="chown" exe="/bin/chown"
type=CWD msg=audit(1145936987.728:183):  cwd="/usr/libexec"
type=PATH msg=audit(1145936987.728:183): item=0 name="/dev/bus/usb/005/005"
flags=1  inode=11287 dev=00:10 mode=020644 ouid=0 ogid=0 rdev=bd:204
type=AVC msg=audit(1145936987.732:184): avc:  denied  { setattr } for  pid=2750
comm="chown" name="005" dev=usbfs ino=11256 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:usbfs_t tclass=file
type=SYSCALL msg=audit(1145936987.732:184): arch=40000003 syscall=212
success=yes exit=0 a0=9a15d60 a1=1f4 a2=ffffffff a3=0 items=1 pid=2750
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="chown" exe="/bin/chown"
type=CWD msg=audit(1145936987.732:184):  cwd="/usr/libexec"
type=PATH msg=audit(1145936987.732:184): item=0 name="/proc/bus/usb/005/005"
flags=1  inode=11256 dev=00:11 mode=0100644 ouid=0 ogid=0 rdev=00:00

Comment 4 Daniel Walsh 2006-04-26 09:14:17 EDT
Try 

restorecon -R -v /var/run/console

And then see if it works.
Comment 5 Dimi Paun 2006-04-26 18:51:58 EDT
That still doesn't work:

[root@dimi ~]# restorecon -R -v /var/run/console
[root@dimi ~]#

BTW, I did a 

[root@dimi ~]# restorecon -R -v /

before reporting the bug, because I was getting thousands
of weird warning messages. For example, when I logged in
at the console right after a reboot, I got this:

dimi login: root
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lib_t:s0) returned
22 for dev=dm-0 ino=1179885
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lib_t:s0) returned
22 for dev=dm-0 ino=1179887
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229402
Password:
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229575
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229391
Last login: Wed Mar 29 00:10:18 on tty1
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_runtime_t:s0)
returned 22 for dev=dm-0 ino=229399
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:ssh_exec_t:s0)
returned 22 for dev=dm-0 ino=5611722
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5613824
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5613912
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5618440
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5608112
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sbin_t:s0) returned
22 for dev=dm-0 ino=5604169
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5606167
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bin_t:s0) returned
22 for dev=dm-0 ino=5605154
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:rpm_exec_t:s0)
returned 22 for dev=dm-0 ino=7913552
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229713
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sbin_t:s0) returned
22 for dev=dm-0 ino=4358239
inode_doinit_with_dentry: 
context_to_sid(system_u:object_r:bootloader_exec_t:s0) returned 22 for dev=dm-0
ino=4358309
inode_doinit_with_dentry:  context_to_sid(root:object_r:user_home_t:s0) returned
22 for dev=dm-0 ino=3391497
inode_doinit_with_dentry:  context_to_sid(root:object_r:user_home_t:s0) returned
22 for dev=dm-0 ino=3391492
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=230060
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229409
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:etc_t:s0) returned
22 for dev=dm-0 ino=229397

It turns out that a _lot_ of files had the wrong context. 
Maybe something didn't work right in the FC4 -> FC5 transition,
but this was a big problem.

I'll attach again the snippet from 
    [root@dimi ~]# tail -f /var/log/audit/audit.log
that I get when I turn on the camera.
Comment 6 Dimi Paun 2006-04-26 18:54:46 EDT
Created attachment 128277 [details]
audit.log trace when digital camera is turned on.

This trace was captured right after a:
    [root@dimi ~]# rpm -q selinux-policy
    selinux-policy-2.2.29-3.fc5
    [root@dimi ~]# restorecon -R -v /var/run/console
Comment 7 Daniel Walsh 2006-04-27 13:38:44 EDT
Looks like these allows are all in selinux-policy-2.2.34-3.fc5
Comment 8 Dimi Paun 2006-04-28 00:18:18 EDT
Created attachment 128339 [details]
audit.log trace when digital camera is turned on (try 2)

This is the trace after selinux-policy-2.2.34-3.fc5 has been applied.
Comment 9 Dimi Paun 2006-04-28 00:20:53 EDT
I'm afraid this is still b0rken:

[root@dimi ~]# rpm -q selinux-policy
selinux-policy-2.2.34-3.fc5
[root@dimi ~]# restorecon -r /
<reboot>
[root@dimi ~]# tail -f /var/log/audit/audit.log
<see Attachment #128339 [details]>
Comment 10 Daniel Walsh 2006-05-01 15:49:02 EDT
That makes no sense.  2.2.34-3.fc5 has these fixes

Did you clear your audit.log?

Could you run 

semodule -b /etc/selinux/targeted/base.pp

To make sure the latest policy is updated?
Comment 11 Dimi Paun 2006-05-01 16:29:05 EDT
It's not a matter of cleaning up audit.log.
I do a:

# tail -f /var/log/audit/audit.log

and see what gets generated when I turn on the camera.
This is what I have submitted. So I know for _sure_
that the messages that I've attached are generated in
response to the camera being turned on.

I will run the semodule -b /etc/selinux/targeted/base.pp
when I get home, but shouldn't that happen automatically
when the policy is updated?

Just to be sure, I've run a 
# restorecon -r /
then rebooted the machine before I've submitted the previous
audit log. So at the very least the contexts where OK.
Comment 12 Dimi Paun 2006-05-02 00:34:25 EDT
OK,

This is weird. I tried to do:
# semodule -b /etc/selinux/targeted/base.pp
but it failed: base.pp was not installed!

It turns out that selinux-policy-targeted-2.2.34-3.fc5
was missing. Beats me why, but there must have been
a problem somewhere.

Nonetheless, after installing the package (and a reboot,
since installing it resulted in the machine freezing solid),
I no longer get the messages in audit.log.

Alas, gthumb doesn't pop-up when the camera powers up,
even if I get these messages in /var/log/messages:

May  2 00:39:10 dimi kernel: usb 5-4.4: new high speed USB device using ehci_hcd
and address 9
May  2 00:39:10 dimi kernel: usb 5-4.4: configuration #1 chosen from 1 choice


Comment 13 Daniel Walsh 2006-05-02 09:47:09 EDT
Does it pop up if you setenforce 0?
Comment 14 Dimi Paun 2006-05-02 23:16:49 EDT
(Un)fortunately no. I think all SELinux problems have been
solved, as I said, there are no more messages generated
in /var/log/audit/audit.log when I turn on the camera.
Comment 16 Daniel Walsh 2007-03-28 16:03:33 EDT
Closing bugs

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