Bug 234483 - avc denial in canna %pre: userdel access to /dev/urandom
Summary: avc denial in canna %pre: userdel access to /dev/urandom
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-29 16:15 UTC by Jerry James
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-13 11:34:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jerry James 2007-03-29 16:15:15 UTC
Description of problem:
I don't know if this is a Canna bug, a shadow-utils bug, or an selinux-policy
bug.  Pardon me if I've filed it under the wrong component.

The %pre script in Canna searches /etc/passwd for a 'canna' entry and calls
userdel if it finds one.  This happens on a Canna upgrade.  When userdel is
invoked, two AVC denials are issued.  The setroubleshoot browser reports both as
denials against "$SOURCE_NAME", indicating that there is an unexpanded macro
somewhere.

Summary: SELinux prevented $SOURCE_NAME from reading from the urandom device.

Raw audit messages:

avc: denied { getattr } for comm="userdel" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/userdel" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="urandom"
path="/dev/urandom" pid=1006 scontext=user_u:system_r:useradd_t:s0 sgid=0
subj=user_u:system_r:useradd_t:s0 suid=0 tclass=chr_file
tcontext=system_u:object_r:urandom_device_t:s0 tty=pts1 uid=0 

Summary: SELinux prevented $SOURCE_NAME from reading from the urandom device.

Raw audit messages:

avc: denied { read } for comm="userdel" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/userdel" exit=13 fsgid=0 fsuid=0 gid=0 items=0 name="urandom"
pid=1006 scontext=user_u:system_r:useradd_t:s0 sgid=0
subj=user_u:system_r:useradd_t:s0 suid=0 tclass=chr_file
tcontext=system_u:object_r:urandom_device_t:s0 tty=pts1 uid=0 

Version-Release number of selected component (if applicable):
Canna-3.7p3-18.fc6
shadow-utils-4.0.17-12.fc6
selinux-policy-2.4.6-46.fc6

How reproducible:
Always

Steps to Reproduce:
1. Install an older version of Canna
2. Upgrade to the latest version
  
Actual results:
The avc denials listed above are issued, with setroubleshoot reporting them as
denials against $SOURCE_NAME.

Expected results:
If the denials are proper, they should be reported against userdel, or possibly
against Canna.  If they are not, they should not be issued.

Additional info:
I am using selinux-policy-targeted in permissive mode.

Comment 1 Daniel Walsh 2007-03-30 13:05:24 UTC
This is strange.  By any chance were you running 

 ProPolice/SSP stack smashing protection

As the troubleshooter suggested?

I will fix the troubleshooter to report the correct path.

Comment 2 Jerry James 2007-03-30 15:58:56 UTC
I thought ProPolice was a compile-time option.  I'm using the unmodified
upstream RPM, if that's what you mean.  Is there some kind of runtime stack
protection option?  If so, I know nothing about it and have not turned it on for
my system.

Comment 3 Daniel Walsh 2007-03-30 16:32:32 UTC
I have no idea, I was just reading the troubleshoot explanation. 

I can think of no reason why userdel would need access to the /dev/urandom.



Comment 4 Jerry James 2007-03-30 17:18:06 UTC
Me neither.  However, I see this in /usr/lib/rpm/redhat/macros:

%__global_cflags	-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4

which seems to mean that EVERY Fedora package is built with ProPolice/SSP stack
smashing protection.


Comment 5 Daniel Walsh 2007-07-13 11:34:32 UTC
I am just going to close this as unreproducable.


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