Bug 244765 - AVC Denials for CPUs using MFC420CN Printer
Summary: AVC Denials for CPUs using MFC420CN Printer
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
(Show other bugs)
Version: 7
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-19 02:20 UTC by Mark Phipps
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-22 14:11:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
six AVC alert messages from the SELinux debugger (14.55 KB, text/plain)
2007-06-19 02:22 UTC, Mark Phipps
no flags Details

Description Mark Phipps 2007-06-19 02:20:23 UTC
Description of problem:
Installed MFC420CN lpr drivers with cupswrapper rpm from manufacturer website here:

and here:


Will not print at all with SELinux Enforcing. Will print perfectly fine with
SELinux disabled or permissive. In permissive, you get many AVC denial errors.
Manufacturers site lists instructions to edit the file_contexts, but they don't

Version-Release number of selected component (if applicable):
CUPS 1.2.10-10.fc7.x86_64
MFC420CNlpr-1.0.2-1.i386.rpm (no x86_64 rpm available)
cupswrapperMFC420CN-1.0.0-1.i386.rpm (no x86_64 rpm available)

I *do not* have cups-lpd or cups-pdf installed

How reproducible:
Very reproducible by turning SE Linux on and off (permissive mode)

Steps to Reproduce:
1. Start with clean fc7 install.
2. install lpr and cupswrapper packages with instructions at:
3. Verify SELinux policy is enforcing
4. Print a test page...no printing
5. Set SELinux to permissive
6. Print a test page
7. See AVC denials

Actual results:
Many AVC denials (see attachment)

Expected results:
No AVC denials

Additional info: See attachment

Comment 1 Mark Phipps 2007-06-19 02:22:28 UTC
Created attachment 157341 [details]
six AVC alert messages from the SELinux debugger

Comment 2 Daniel Walsh 2007-06-19 12:42:25 UTC
Do you know what directory it is trying to create files in?


Did you run it in permissive mode?  When you run it a second time, does it try
to unlink the file again?

Comment 3 Mark Phipps 2007-06-21 02:45:10 UTC
Yes, I ran it in permissive mode in order to see the denials--in enforcing mode
it would not print at all.

It appears to be attempting to modify the file "brMFC420CNrc" which is in the
/usr/local/Brother/inf directory. The brMFC420CNrc file has information like the
print resolution, paper type, etc.

When trying different file-contexts, I did full system re-boots just to be sure
everything was reset. It may require that I create a local policy to avoid the
situation, but I haven't gotten that far yet.

Comment 4 Daniel Walsh 2007-06-21 12:55:27 UTC
See if 

#chcon -R -t cups_rw_etc_t /usr/local/Brother/inf

Makes it work.

This should be brought up as a bug to Brother that they should not have r/w
files under /usr.  They should be under /var or /etc/.  (Preferably /var).  If
this works for you I will change the default policy to label this directory.

Comment 5 Mark Phipps 2007-06-25 01:48:38 UTC
That takes care of most of the issues. I think you really meant chcon -R -t
cupsd_rw_etc_t (cupsd instead of cups).  The only denials now concern the
cupswrapper file trying to do various things (lock, get_addr, etc)with
/var/run/utmp.  It will now print in enforcing mode, but you still get a few
denials regarding /var/run/utmp.

The file that is trying to access /var/run/utmp is brlpdwrapperMFC and is
located in the usr/lib/cups/filter folder.  By default it has the following
context: system_u:object_r:bin_t

Whatever it is trying to do doesn't stop the print job from execution, even in
enforcing mode, but does pop up with AVC denials.

Comment 6 Daniel Walsh 2007-06-25 10:36:34 UTC
Ok, I will add a dontaudit rule for the next selinux-policy update along with
fixing the labeling of that directory.

fixed in selinux-policy-2.6.4-23

Comment 7 Daniel Walsh 2007-08-22 14:11:03 UTC
Closing as fixes are in the current release

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