Bug 498181 - Lots of selinux denials from foomatic
Summary: Lots of selinux denials from foomatic
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: foomatic
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-29 10:39 UTC by Mary Ellen Foster
Modified: 2009-04-30 08:56 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-30 08:56:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mary Ellen Foster 2009-04-29 10:39:59 UTC
Description of problem:
I just tried using system-config-printer to add a new printer, and just choosing the "New Printer" menu item resulted in a spew of selinux denials. I'll include the details of one of the 198:

SELinux is preventing foomatic (cupsd_t) "search" mnt_t.
Additional Information
Source Context:  system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context:  unconfined_u:object_r:mnt_t:s0
Target Objects:  local [ dir ]Source:  cups-driverd
Source Path:  /usr/lib/cups/daemon/cups-driverd
Port:  <Unknown>
Host:  snape
Source RPM Packages:  perl-5.10.0-68.fc11
Target RPM Packages:  
Policy RPM:  selinux-policy-3.6.12-9.fc11
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  catchall
Host Name:  snape
Platform:  Linux snape 2.6.29.1-111.fc11.x86_64 #1 SMP Fri Apr 24 10:57:09 EDT 2009 x86_64 x86_64
Alert Count:  198
First Seen:  Wed 29 Apr 2009 11:14:05 AM BST
Last Seen:  Wed 29 Apr 2009 11:26:24 AM BST
Local ID:  09cf4cfd-3d68-4e34-8508-126c027123a8
Line Numbers:  
Raw Audit Messages :
node=snape type=AVC msg=audit(1241000784.925:125): avc: denied { search } for pid=2680 comm="foomatic" name="local" dev=sda7 ino=13 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mnt_t:s0 tclass=dir
node=snape type=SYSCALL msg=audit(1241000784.925:125): arch=c000003e syscall=4 success=no exit=-1543348264 a0=2375dc8 a1=7fffc6b41a90 a2=7fffc6b41a90 a3=352f6c7265705f65 items=0 ppid=2678 pid=2680 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm="foomatic" exe="/usr/bin/perl" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) 

Version-Release number of selected component (if applicable):
foomatic-4.0.0-2.fc11.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Run system-config-printer
2. Choose Server-New-Printer
3. Enter root password
  
Actual results:
Lots of AVC denials (about 100 each time)

Expected results:
No denials :)

Comment 1 Tim Waugh 2009-04-29 16:28:07 UTC
This sounds more like a local configuration problem.  Do you perhaps have a filesystem mounted at /usr/local, and does that filesystem's root inode have 'mnt_t' as its security type?  That directory is meant to be type usr_t so that applications can look in /usr/local/bin as part of the normal $PATH traversal (for instance).

Comment 2 Mary Ellen Foster 2009-04-30 08:15:01 UTC
Aha, yes, good point -- I have one partition for "/" and another, mounted on "/hd", with the following bind mounts:
- "/hd/home" mounted at "/home"
- "/hd/local" mounted at "/usr/local"

The labels on /hd/home and /hd/local are (now) correct, I think:
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /hd/home
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /hd/local

But you're right, the label on /hd itself is:
drwxr-xr-x. root root system_u:object_r:default_t:s0   /hd

I guess this partitioning scheme doesn't play nice with selinux. :( I've always disabled selinux before, so I didn't notice, but this time I left it enabled and I guess this is the result.

Comment 3 Tim Waugh 2009-04-30 08:45:31 UTC
So what does 'ls -Zd /usr /usr/local /usr/local/bin' say?

Comment 4 Mary Ellen Foster 2009-04-30 08:56:36 UTC
% ls -Zd /usr /usr/local /usr/local/bin
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /usr
drwxr-xr-x. root root system_u:object_r:usr_t:s0       /usr/local
drwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/local/bin
%

But I'm sorry for the spam -- after booting this morning, the problem seems to have gone away. I guess all of my frantic relabelling yesterday did in fact solve things after all, and it just needed a fresh boot to see things right.

Sorry about that. :(


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