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

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.

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

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.

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)

Created attachment 99123 [details]
/var/log/messages denied messages for pam_console_apply

This looks like the /dev directory was never labeled.  

Dan

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

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?

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.

Make relabel should have fixed the problem

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

Dan

Is this on an ext3 file system?

Dan

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

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

setfiles done ... looks much better now.

I do not know what you mean by "What does your mount command show?"

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

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.

Created attachment 99135 [details]
mount .... single partition holds all

Ok, I have no idea, what went wrong.

Are you using fixfiles or make relabel?

Dan

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.

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.

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

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

This suddenly started working correctly in the last day or two.