Bug 119309 - pam_console fails to give permissions.
pam_console fails to give permissions.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: SELinux
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-03-29 05:38 EST by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-22 16:14:01 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)
/var/log/messages denied messages for pam_console_apply (13.08 KB, text/plain)
2004-04-05 16:44 EDT, Gene Czarcinski
no flags Details
mount .... single partition holds all (226 bytes, text/plain)
2004-04-06 07:14 EDT, Gene Czarcinski
no flags Details

  None (edit)
Description Aleksey Nogin 2004-03-29 05:38:49 EST
When I log in via kdm on a local display, the devices that are
supposed to change permissions stay owned bo root. I see

Mar 29 02:23:57 dell kernel: audit(1080555837.513:0): avc:  denied  {
read } for  pid=3552 exe=/sbin/pam_console_apply name=console.lock
dev=hda2 ino=179988 scontext=system_u:system_r:pam_console_t
tcontext=system_u:object_r:xdm_var_run_t tclass=file

repeated several times.

I have policy-sources-1.9-15 pam-0.77-38
Comment 1 Daniel Walsh 2004-03-29 08:23:38 EST
I don't think that is causing all of you problems add
ifdef(`xdm', `
allow pam_console_t xdm_var_run_t:file { getattr read };
')
to pam console and you will get beyond this bug, but could you run try
this in non enforcing and get the entire list of console messages.

Also thanks alot for all the help you have been giving us. 

Dan
Comment 2 Aleksey Nogin 2004-03-29 16:51:07 EST
I've added 

allow pam_console_t xdm_var_run_t:file { read };

to my file of local policy mods and this did help somewhat - some of
the files (e.g. /dev/mixer) get chowned correctly, but some (/dev/hdc
linked by /dev/cdrom) still do not for some reason. But this time I do
not see any AVC messages.
Comment 3 Daniel Walsh 2004-03-30 10:10:19 EST
try policy-1.9.1-2 which has this fix in rawhide.  Could you try it
with setenforce 0 and see if you get avc messages.

Dan
Comment 4 Aleksey Nogin 2004-04-02 01:43:59 EST
With policy-sources-1.9.2-1 in enforcing mode I only get the audio
devices, other stay owned byt root. In permissive mode I get all of
them. No AVC messages either way.
Comment 5 Gene Czarcinski 2004-04-05 16:43:01 EDT
With policy 1.9.2-10 I am seeing messages of the form:

Apr  5 13:15:48 chaos kernel: audit(1081185294.250:0): avc:  denied  {
getattr } for  pid=922 exe=/sbin/pam_console_apply path=/dev/fd0
dev=hda7 ino=681130 scontext=system_u:system_r:pam_console_t
tcontext=system_u:object_r:device_t tclass=blk_file
Apr  5 13:15:48 chaos kernel: audit(1081185294.485:0): avc:  denied  {
getattr } for  pid=922 exe=/sbin/pam_console_apply path=/dev/dsp
dev=hda7 ino=669430 scontext=system_u:system_r:pam_console_t
tcontext=system_u:object_r:device_t tclass=chr_file

I am attaching the rest (lots of messages)

Comment 6 Gene Czarcinski 2004-04-05 16:44:11 EDT
Created attachment 99123 [details]
/var/log/messages denied messages for pam_console_apply
Comment 7 Daniel Walsh 2004-04-05 16:57:46 EDT
This looks like the /dev directory was never labeled.  

Dan
Comment 8 Gene Czarcinski 2004-04-05 17:20:35 EDT
With all of the "make relabel" I did it should be ... and is.

All the ones I looked at at system_r:system_u:device_t
Comment 9 Daniel Walsh 2004-04-05 17:38:25 EDT
ls -lZ /dev/fd0
brw-rw----+ dwalsh   floppy   system_u:object_r:removable_device_t
/dev/fd0
[root@celtics policy]# ls -lZ /dev/dsp
crw-------+ dwalsh   root     system_u:object_r:sound_device_t /dev/dsp
ls -Z /dev/audio
crw-------+ dwalsh   root     system_u:object_r:sound_device_t /dev/audio
????
You are not seeing this?
Comment 10 Gene Czarcinski 2004-04-05 17:53:30 EDT
No, I am not ... all of mine are system_u:object_r:device_t (not what
I said above).

[root@chaos root]# ls -Z /dev/fd0 /dev/dsp /dev/audio
crw-------  root     root     system_u:object_r:device_t       /dev/audio
crw-------+ root     root     system_u:object_r:device_t       /dev/dsp
brw-rw----+ root     floppy   system_u:object_r:device_t       /dev/fd0

I do not know if running "make relabel" caused this problem but I
suppose I could run it yet again.
Comment 11 Daniel Walsh 2004-04-05 18:15:14 EDT
Make relabel should have fixed the problem

Do a 
/sbin/restorecon /dev/audio 
and see what the context is?

Dan
Comment 12 Daniel Walsh 2004-04-05 18:15:55 EDT
Is this on an ext3 file system?

Dan
Comment 13 Gene Czarcinski 2004-04-05 18:32:04 EDT
Yes, I use only ext2 currently.

[root@chaos root]# /sbin/restorecon /dev/audio
[root@chaos root]# ls -Z /dev/fd0 /dev/dsp /dev/audio
crw-------  root     root     system_u:object_r:sound_device_t /dev/audio
crw-------+ root     root     system_u:object_r:device_t       /dev/dsp
brw-rw----+ root     floppy   system_u:object_r:device_t       /dev/fd0
Comment 14 Daniel Walsh 2004-04-05 21:32:11 EDT
Ok something is going wrong on make relabel.

Try 

setfiles /etc/security/selinux/file_contexts /dev

Should clean it up.

What does your mount command show?

Dan
Comment 15 Gene Czarcinski 2004-04-06 03:39:43 EDT
setfiles done ... looks much better now.

I do not know what you mean by "What does your mount command show?"
Comment 16 Gene Czarcinski 2004-04-06 04:19:00 EDT
Mmmm ... that is strange.

OK, after I ran setfiles, everything in /dev/snd/* was labeled
system_u:object_r:sound_device_t

I was logged in with my sysadm userid as well as ssh in as root and su
- as root.  Most of the devices have ownerid of my sysadm user
although a few have root.

I then rebooted and logged in again as my sysadm userid plus su - as
root.  I do ls -Z /dev/snd/* and oops most of the files are still
system_u:object_r:sound_device_t but a few (all with ownerid of root)
are now system_u:object_r:device_t
Comment 17 Daniel Walsh 2004-04-06 06:30:30 EDT
mount > /tmp/showme
Then attach showme.  :^)

I am thinking there is something broken in the makefile that is
causing setfiles not to relable you /dev directory.


The Makefile is doing

 $(SETFILES) $(FC) `mount | grep -v "context=" | awk '/(ext[23]|
xfs).*rw/{print $$3}'`

And it is not relableing you /dev directory so I need to look at yours
 to see what is going on.
Comment 18 Gene Czarcinski 2004-04-06 07:14:05 EDT
Created attachment 99135 [details]
mount .... single partition holds all
Comment 19 Daniel Walsh 2004-04-06 07:25:33 EDT
Ok, I have no idea, what went wrong.

Are you using fixfiles or make relabel?

Dan
Comment 20 Gene Czarcinski 2004-04-06 07:41:09 EDT
fixfiles

I am tempted to grab a snapshot of the development tree and do a fresh
install (I have the "extra" partitions so this system would not be
wiped). Sometimes a completely fresh install will cleanup problems
caused by updating which leaves things in a questionable state.
Comment 21 Aleksey Nogin 2004-04-06 16:08:58 EDT
Guys, 

Somehow you morphed this bug from "pam_console fails to give
permissions" (even when /dev/is labeled correctly) to "/dev was not
labeled correctly". Please note that the original bug _still stands_ -
the situation is still how I described it in comment #2 - even with an
additional local "allow", the removable devices (e.g. /dev/fd0 and
/dev/hdc that is pointed to by /dev/cdrom) still end up being owned by
root: 

% ls -lZ /dev/audio /dev/fd0
crw-------+ aleksey  root     system_u:object_r:sound_device_t /dev/audio
brw-rw----+ root     floppy   system_u:object_r:removable_device_t
/dev/fd0

I do not see anything in the logs.
Comment 22 Daniel Walsh 2004-04-06 16:19:00 EDT
Ok try this 

make -c /etc/selinux/selinux/src/policy enableaudit
make -c /etc/selinux/selinux/src/policy load

Now try to login and see if pam_console generates any messages.

Dan

dontaudit pam_console_t hotplug_etc_t:dir { search };

Might be causing the problem
Comment 23 Tim Waugh 2004-04-08 12:36:38 EDT
I'm getting this in enforcing mode with policy-1.10.1-4:

audit(1081441849.241:0): avc:  denied  { read } for  pid=9464
exe=/sbin/pam_console_apply name=console.lock dev=hda2 ino=1017183
scontext=system_u:system_r:pam_console_t
tcontext=system_u:object_r:xdm_var_run_t tclass=file
Comment 24 Aleksey Nogin 2004-04-21 02:51:32 EDT
This suddenly started working correctly in the last day or two.

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