$subj ... by letting processes that use PAM for session setup send netlink messages to the audit subsystem. So far I have collected: allow local_login_t self:netlink_audit_socket nlmsg_write; allow sshd_t self:netlink_audit_socket nlmsg_write; allow xdm_t self:netlink_audit_socket nlmsg_write; Version-Release number of selected component (if applicable): selinux-policy-targeted-3.0.8-72.fc8
I can fix it, how can I test it? Thank you for reply!
Basically, append to /etc/pam.d/system-auth: session required pam_tty_audit.so disable=* enable=root and try as many ways to log in / switch to the root user as you can think of. Some more detailed instructions are available in https://bugzilla.redhat.com/show_bug.cgi?id=244352#c10 - but note that TTY auditing will still not work in some cases unless you patch the kernel.
I believe this is a bug in the pam module, it should not be requesting nlmsg_write. It should use nlmsg_relay. Requiring So far I have collected: allow local_login_t self:netlink_audit_socket nlmsg_write; allow sshd_t self:netlink_audit_socket nlmsg_write; allow xdm_t self:netlink_audit_socket nlmsg_write; Will allow all of the login programs to change the auditing level and what gets audited, I also think it can turn off auditing.
Type of the access needed is determined by kernel, not the pam module itself. If it was changed to nlmsg_relay it would be the same type as auditing message. That would mean that any process which can send audit messages can enable/disable tty auditing. This might be undesirable. But I agree that using nlmsg_write is not a good idea either. Perhaps a new type should be added?
sgrubb what is the latest on this?
Eric can you look into this?
The patch I sent was this one: http://marc.info/?l=selinux&m=120491226616954&w=2
I'll try to look at it eventually. sds was nice enough to clearly lay out the steps required for adding a new permission to the kernel its also at http://www.selinuxproject.org/page/Adding_New_Permissions in order to not forget everywhere changes are required. We put the big headers stating not to edit by hand for a reason :) I'll try to get to it before F10 if noone else wants to finish the halfway completed work.
Created attachment 317173 [details] refpolicy patch
Created attachment 317174 [details] libselinux patch
Created attachment 317176 [details] kernel patch
These are the patches generated using the directions in comment #9. The libselinux patch is way too large, it seems libselinux git has not caught up with some refpolicy changes. > There is also the backward compatibility issue - we must not break > akpm's system if he boots a new kernel on an existing distro that lacks > new policy. I have no idea what to do about this. Anyway, this affects only systems that use pam_tty_audit. Currently such systems don't work with SELinux anyway, so booting a new kernel without new rules in policy cannot hurt anything - but I'm not sure whether a new kernel can handle a policy that does not refer to the new capability, or whether an old kernel can handle a policy that does refer to the new capability.
What was the libselinux patch made against? It looks like the original libselinux files were really quite old and your patch very well could be the right thing to do. (Or maybe we have to break up and fix the OPEN/X/your fixes into 3 patches) Lets not worry about kernel backwards compat here. Noone's using this stuff yet anyway :)
(In reply to comment #14) > What was the libselinux patch made against? http://oss.tresys.com/git/selinux.git
Definition is in libselinux-2.0.71-5.fc10 Definition is in selinux-policy-3.5.8-5.fc10.noarch
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
things to do. 1) define new perm in refpolicy 2) define new perm in kernel 3) implement new perm in refpolicy 4) implement new perm in kernel dwalsh did set 1. I'm starting on 2 and 4 today.
Patch sent to selinux list.