Bug 429524

Artem, are you running SELinux in enforcing mode?  (I suspect that the policy
isn't allowing this, because the traditional Unix permissions should allow any
process to connect to the socket.)  If you are, can you enable the "audit"
service, try it again, and attach the output of "ausearch -ts recent -m avc"?

Thanks!

[root@birdie ~]# cat /etc/selinux/config  | grep SELINUX
# SELINUX= can take one of these three values:
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
SELINUXTYPE=targeted

[root@birdie ~]# ausearch -ts recent -m avc
<no matches>

Besides SeLinux policy doesn't apply to usual users ;-)

This what happens if I sudo su - :

Password:
com.redhat.oddjob.Error.NoInterface: com.redhat.oddjob_mkhomedir

Yup, it looks like you've found _two_ bugs, one in the policy (I think Dan's
working on that one) and a bug in the /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf
which is distributed with the package.

The pam_oddjob_mkhomedir.so module, as you can see, is expecting to call methods
provided as part of an interface named "com.redhat.oddjob_mkhomedir", while the
configuration file defines them as part of an interface named
"com.redhat._mkhomedir", because I got that part wrong when I changed the
interface name to decouple it from the rest of the methods provided by oddjobd
itself.

I've made that fix in CVS, and will try to get a test update spun today. 
Meanwhile, if you can verify that the configuration file change, followed by
"/sbin/service oddjobd reload" works (even if only in SELinux permissive mode),
that'd be great.

Thanks!

oddjob-0.29-2.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update oddjob'

Jan 25 13:42:22 Updated: oddjob-libs - 0.29-2.fc8.i386
Jan 25 13:42:24 Updated: oddjob - 0.29-2.fc8.i386
Jan 25 13:42:24 Updated: oddjob-mkhomedir - 0.29-2.fc8.i386

[birdie@birdie ~]$ ssh birdie-dca.0.1
birdie-dca.0.1's password:
org.freedesktop.DBus.Error.AccessDenied: Failed to connect to 
socket /var/run/dbus/system_bus_socket: Permission denied
Last login: Tue Jan 22 10:32:24 2008 from localhost.localdomain
Could not chdir to home directory /home/birdie-dca: No such file or directory
/usr/bin/xauth:  error in locking authority file /home/birdie-dca/.Xauthority
-bash-3.2$ pwd
/

[birdie@birdie ~]$ sudo su -
Password:
com.redhat.oddjob.Error.ACL: ACL does not allow access

In a text console when I try to log in I get this error message:

localhost login: birdie
Password:
org.freedesktop.DBus.Error.AccessDenied: An SELinux policy prevents this 
sender
from sending this message to this recipient (rejected message had 
interface "com.redhat.oddjob_mkhomedir" member "mkhomedirfo
r" error name "(unset)" destination "com.redhat.oddjob_mkhomedir")
Last login: Wed Jan 30 11:58:22 on :0

Fixed in selinux-policy-3.0.8-83

oddjob-0.29-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

selinux-policy-3.0.8-83 is still not in F8 updates repo - is that OK?

With oddjob-0.29-2.fc8 from test updates I still get errors:

[birdie@birdie ~]$ su -
Password:
com.redhat.oddjob.Error.ACL: ACL does not allow access

83 should be in test-updates now.

No luck with the latest selinux-policy from testing updates:

rpm -qa | grep selinux-policy

selinux-policy-targeted-3.0.8-83.fc8
selinux-policy-3.0.8-83.fc8
selinux-policy-devel-3.0.8-83.fc8

rpm -qa | grep oddjob

oddjob-libs-0.29-2.fc8
oddjob-0.29-2.fc8
oddjob-mkhomedir-0.29-2.fc8

[birdie@birdie ~]$ ssh birdie-dca.0.1
birdie-dca.0.1's password:
com.redhat.oddjob.Error.Exec: Child signalled exec() error: Permission denied.
Last login: Fri Jan 25 13:42:45 2008 from localhost.localdomain
Could not chdir to home directory /home/birdie-dca: No such file or directory
/usr/bin/xauth:  error in locking authority file /home/birdie-dca/.Xauthority
-bash-3.2$

Are you seeing any AVC messages in /var/log/audit/audit.log?

Created attachment 294977 [details]
bzipped /var/log/audit

Yes, I have AVC errors:

audit2allow < /var/log/audit/audit.log

#============= crond_t ==============
allow crond_t oddjob_t:dbus send_msg;

#============= httpd_squid_script_t ==============
allow httpd_squid_script_t self:udp_socket create;

#============= oddjob_t ==============
allow oddjob_t local_login_t:process transition;
allow oddjob_t sshd_t:process transition;
allow oddjob_t xdm_t:process transition;

#============= squid_t ==============
allow squid_t port_t:tcp_socket name_connect;
allow squid_t src_t:dir getattr;

#============= tftpd_t ==============
allow tftpd_t winbind_var_run_t:dir getattr;

#============= unconfined_t ==============
allow unconfined_t self:process execheap;
allow unconfined_t user_home_t:file execmod;

Is oddjob_mkhomedir pam module after the pam_selinux open call in the pam file?

Looks like you put it in the system-auth file.

I will be adding some other fixes from your audit.log also.


A couple of other comments?

If you want to allow squid to connect to random other ports you can turn on the

squid_connect_any boolean

setsebool -P squid_connect_any=1

Not sure why squid is looking at /usr/src

httpd_squid_script_t looks like it is trying to connect to dns, I will fix this.


tftpd_t is using winbind through nsswitch I will fix this.

cat /etc/pam.d/system-auth-ac

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session     required      pam_unix.so

# birdie - create a home dir for newly logged on users
session     required      pam_oddjob_mkhomedir.so skel=/etc/skel umask=0022
# birdie

With selinux-policy-targeted  noarch     3.0.8-84.fc8 installed:

[birdie@birdie ~]$ ssh birdie-dca.0.1
birdie-dca.0.1's password:
com.redhat.oddjob.Error.Exec: Child signalled exec() error: Permission denied.
Last login: Fri Feb 15 10:48:50 2008 from localhost.localdomain
Could not chdir to home directory /home/birdie-dca: No such file or directory
/usr/bin/xauth:  error in locking authority file /home/birdie-dca/.Xauthority

su -
Password:
com.redhat.oddjob.Error.ACL: ACL does not allow access


tail -100 /var/log/audit/audit.log | audit2allow

#============= crond_t ==============
allow crond_t oddjob_t:dbus send_msg;

#============= oddjob_t ==============
allow oddjob_t sshd_t:process transition;

session     required      pam_oddjob_mkhomedir.so skel=/etc/skel umask=0022

should not be in the system-auth file.  It should be in /etc/pam.d/sshd and
/etc/pam.d/login 

It has to be called after pam_selinux open call.

Cron should never call pam_oddjob_mkhomedir.so

You should update or add documentation about oddjob since even RH pages give 
wrong instructions: http://kbase.redhat.com/faq/FAQ_85_9091.shtm , 
http://www.redhat.com/magazine/024oct06/features/tips_tricks/

Besides, if I understand you correctly then we also have to add 
pam_oddjob_mkhomedir to XDM pam.d service.

Well, I have added "session required  pam_oddjob_mkhomedir.so skel=/etc/skel 
umask=0022" to sshd, login and xdm services (all daemons have been restarted). 
Alas, nothing works:

[birdie@birdie ~]$ ssh birdie-dca.0.1
birdie-dca.0.1's password:
com.redhat.oddjob.Error.Exec: Child signalled exec() error: Permission denied.
Last login: Tue Feb 19 10:51:02 2008 from localhost.localdomain
Could not chdir to home directory /home/birdie-dca: No such file or directory
/usr/bin/xauth:  error in locking authority file /home/birdie-dca/.Xauthority

Besides SeLinux errors are still here.

#============= oddjob_t ==============
allow oddjob_t local_login_t:process transition;
allow oddjob_t sshd_t:process transition;
allow oddjob_t xdm_t:process transition;

The last thing I wonder is that why isn't it possible to user pam_mkhomedir.so 
with SeLinux? All logon/login daemons run under root, so it must be possible 
to create a user home directory without extra fuss (like running an extra 
daemon), just before dropping permissions.

It is possible and works here.

Did you remove pam_oddjob_mkhomedir from system-auth-ac?

Did you place pam_oddjob_mkhomedir  after pam_selinux open?

Created attachment 295307 [details]
My /etc/pam.d/login (rawhide)

Created attachment 295382 [details]
Entire /etc/pam.d tar.bz'ipped

Yes, system-auth-ac is in its default configuration.

Ok fixed in selinux-policy-3.0.8-88.fc8

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping