Fixed in selinux-policy-3.10.0-128.fc17

This is a bit strange, but with that policy applied it still doesn't seem to work unless I go to permissive mode.

The strange bit though, is that I'm not seeing any AVCs at all, yet switching to permissive mode makes it work.

Try it with dontaudit rules off.

# semodule -DB
Run your app
# semodule -B

Look for new AVC messages.

Yes, that found a load more AVCs:

time->Thu Jun  7 20:42:55 2012
type=AVC msg=audit(1339098175.088:5307): avc:  denied  { rlimitinh } for  pid=9330 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process
----
time->Thu Jun  7 20:42:55 2012
type=AVC msg=audit(1339098175.088:5308): avc:  denied  { siginh } for  pid=9330 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process
----
time->Thu Jun  7 20:42:55 2012
type=AVC msg=audit(1339098175.089:5309): avc:  denied  { noatsecure } for  pid=9330 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process
----
time->Thu Jun  7 20:53:21 2012
type=AVC msg=audit(1339098801.916:5343): avc:  denied  { read } for  pid=9361 comm="httpd" name="mls" dev="selinuxfs" ino=12 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file
----
time->Thu Jun  7 20:53:21 2012
type=AVC msg=audit(1339098801.916:5344): avc:  denied  { open } for  pid=9361 comm="httpd" name="mls" dev="selinuxfs" ino=12 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file
----
time->Thu Jun  7 20:53:21 2012
type=AVC msg=audit(1339098801.988:5345): avc:  denied  { rlimitinh } for  pid=9362 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process
----
time->Thu Jun  7 20:53:21 2012
type=AVC msg=audit(1339098801.988:5346): avc:  denied  { siginh } for  pid=9362 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process
----
time->Thu Jun  7 20:53:21 2012
type=AVC msg=audit(1339098801.989:5347): avc:  denied  { noatsecure } for  pid=9362 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process
----
time->Thu Jun  7 20:53:22 2012
type=AVC msg=audit(1339098802.032:5348): avc:  denied  { getattr } for  pid=9362 comm="systemd-ask-pas" path="/run/systemd" dev="tmpfs" ino=1944 scontext=system_u:system_r:httpd_passwd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir
----
time->Thu Jun  7 20:53:26 2012
type=AVC msg=audit(1339098806.557:5350): avc:  denied  { siginh } for  pid=9372 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process
----
time->Thu Jun  7 20:53:26 2012
type=AVC msg=audit(1339098806.558:5351): avc:  denied  { noatsecure } for  pid=9372 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process
----
time->Thu Jun  7 20:53:26 2012
type=AVC msg=audit(1339098806.557:5349): avc:  denied  { rlimitinh } for  pid=9372 comm="missing" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process

Fixed in selinux-policy-3.10.0-129.fc17


You can check this by executing

# grep init_var_run_t /var/log/audit/audit.log | audit2allow -M mysystemd
# semodule -i mysystemd.pp

Well that fixes one of the AVCs yes, but it still leaves these:

time->Fri Jun  8 09:52:55 2012
type=AVC msg=audit(1339145575.342:7554): avc:  denied  { read } for  pid=19868 comm="httpd" name="mls" dev="selinuxfs" ino=12 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file
----
time->Fri Jun  8 09:52:55 2012
type=AVC msg=audit(1339145575.342:7555): avc:  denied  { open } for  pid=19868 comm="httpd" name="mls" dev="selinuxfs" ino=12 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file
----
time->Fri Jun  8 09:52:55 2012
type=AVC msg=audit(1339145575.407:7556): avc:  denied  { rlimitinh } for  pid=19869 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process
----
time->Fri Jun  8 09:52:55 2012
type=AVC msg=audit(1339145575.407:7557): avc:  denied  { siginh } for  pid=19869 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process
----
time->Fri Jun  8 09:52:55 2012
type=AVC msg=audit(1339145575.408:7558): avc:  denied  { noatsecure } for  pid=19869 comm="httpd-ssl-pass-" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_passwd_t:s0 tclass=process

Well you can turn off the dontaudit rules if the app works.

semodule -B

Well that's the point, even with that custom module it doesn't work unless I go into permissive mode...

Ok change the custom policy to add all of those alerts and see if it works.

Right, so I rebuild the custom policy to cover all those AVCs, and it still fails unless I am in permissive mode.

So in summary, in permissive mode it works, with no AVCs (not even dontaudit ones) and in enforcing mode it fails.

Basically systemd-ask-password is failing to create the file in /run/systemd/ask-password that would trigger the password prompt. Watching with inotifywait I can see that in enforcing mode the only events are:

/run/systemd/ask-password/ OPEN,ISDIR 
/run/systemd/ask-password/ CLOSE_NOWRITE,CLOSE,ISDIR 

while in permissive mode you get:

/run/systemd/ask-password/ OPEN,ISDIR 
/run/systemd/ask-password/ CLOSE_NOWRITE,CLOSE,ISDIR 
/run/systemd/ask-password/ CREATE tmp.GlVgCL
/run/systemd/ask-password/ OPEN,ISDIR 
/run/systemd/ask-password/ CLOSE_NOWRITE,CLOSE,ISDIR 
/run/systemd/ask-password/ OPEN tmp.GlVgCL
/run/systemd/ask-password/ ATTRIB tmp.GlVgCL
/run/systemd/ask-password/ CREATE sck.3176690537257226118
/run/systemd/ask-password/ MODIFY tmp.GlVgCL
/run/systemd/ask-password/ MOVED_FROM tmp.GlVgCL
/run/systemd/ask-password/ OPEN,ISDIR 
/run/systemd/ask-password/ MOVED_TO ask.GlVgCL
...

etc

And you are not seeing any avc messages with dontaudit rulese disabled?

semdoule -DB
setenforce 0
Attempt your connection
Look for AVC's.  I would think we are still not giving it permission to search through /run/systemd/ask-password.

Absolutely sure... I just did this:

centurion [~] % getenforce
Permissive
centurion [~] % sudo semodule -DB 
...
centurion [~] % sudo systemctl restart httpd.service
Enter SSL pass phrase for www.example.com:443 (RSA) : ********

and all I that got added to audit.log is:

type=USER_AUTH msg=audit(1339166732.831:8599): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="thh" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=USER_ACCT msg=audit(1339166732.848:8600): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="thh" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=USER_CMD msg=audit(1339166732.854:8601): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/thh" cmd=73797374656D63746C20726573746172742068747470642E73657276696365 terminal=pts/1 res=success'
type=CRED_ACQ msg=audit(1339166732.859:8602): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=USER_START msg=audit(1339166732.867:8603): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=SERVICE_STOP msg=audit(1339166734.467:8604): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1339166742.743:8605): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_END msg=audit(1339166742.760:8606): pid=0 uid=0 auid=2067 ses=685 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'

then if I turn enforcing on:

centurion [~] % sudo setenforce 1  
centurion [~] % sudo systemctl restart httpd.service
Job failed. See system journal and 'systemctl status' for details.

Strange do you see any AVC's in /var/log/messages?

Not any AVCs as such, though there is one strange message when the polic reloaded. Here are the messages from when I reloaded to turn off dontaudit:

Jun  8 15:42:18 centurion kernel: [190138.696800] SELinux:  Permission ptrace_child in class process not defined in policy.
Jun  8 15:42:18 centurion kernel: [190138.697680] SELinux: the above unknown classes and permissions will be allowed
Jun  8 15:42:29 centurion dbus-daemon[537]: dbus[537]: avc:  received policyload notice (seqno=11)
Jun  8 15:42:29 centurion dbus[537]: avc:  received policyload notice (seqno=11)
Jun  8 15:42:30 centurion dbus-daemon[537]: dbus[537]: [system] Reloaded configuration
Jun  8 15:42:30 centurion dbus[537]: [system] Reloaded configuration

and the messages from setting enforcing mode and then doing a failed restart:

Jun  8 15:47:50 centurion dbus-daemon[537]: dbus[537]: avc:  received setenforce notice (enforcing=1)
Jun  8 15:47:50 centurion dbus[537]: avc:  received setenforce notice (enforcing=1)
Jun  8 15:47:50 centurion dbus-daemon[537]: dbus[537]: [system] Reloaded configuration
Jun  8 15:47:50 centurion dbus[537]: [system] Reloaded configuration
Jun  8 15:47:53 centurion systemd[1]: httpd.service: control process exited, code=exited status=1
Jun  8 15:47:53 centurion systemd[1]: Unit httpd.service entered failed state.

Have all userspace components that previously did their own direct calls to security_compute_av or used libselinux checkPasswdAccess or selinux_check_passwd_access() been converted over to using selinux_check_access()?  If not, then you might be getting userspace permission denials without AVC messages, as per old bug 518268.

Another possibility is that I think you directly checking enforcing mode in some userspace code and if permissive, succeed even in the face of errors other than permission denials, which wouldn't get logged.  So that would be something to check.

What exact userspace components are involved in this transaction?  pam modules?  shadow-utils programs?

So basically apache is running /usr/libexec/httpd-ssl-pass-dialog from the mod_ssl package, which is just a simple shell script:

#!/bin/sh

exec /bin/systemd-ask-password "Enter SSL pass phrase for $1 ($2) : "

then /bin/systemd-ask-password is trying to create a socket and a text file in /run/systemd/ask-password which systemd will detect with inotify and which will trigger it into prompting for a password.

The actual code which is running shoud be this:

http://cgit.freedesktop.org/systemd/systemd/tree/src/ask-password-api.c?id=16f1239e1ece27257c0deedcf01aa39474f66241#n326

I'm think it is getting as far as the mkdir_p() call, because something it accessing the directory, but clearly it never gets as far as creating the file a few lines later. The mkdir_p code is hre:

http://cgit.freedesktop.org/systemd/systemd/tree/src/util.c?id=16f1239e1ece27257c0deedcf01aa39474f66241#n1648

I guess the interesting thing there is that it uss label_mkdir, which does do selinux stuff - you can see that here:

http://cgit.freedesktop.org/systemd/systemd/tree/src/label.c?id=16f1239e1ece27257c0deedcf01aa39474f66241#n286

Dan, in label.c, in any situation where you permit it to proceed if not enforcing, you need to log a message if it wasn't due to a permission denial so that it is possible to debug such failures.  Also, I see that in various cases, the logs are done at LOG_DEBUG rather than LOG_ERR if not enforcing there.  How does one turn up debug logging for systemd?  That also seems prone to hiding errors in permissive mode.

Created attachment 590965 [details]
This patch will turn the log_debugs to log_errors even in permissive mode.

I added a log_error to show it is in permissive mode.

After some mucking about I have now managed to get to see the log messages reported by systemd-ask-password (which go to stderr which is discarded by apache) and I can now reveal that the following is reported:

Failed to create password file: Permission denied

which indicates that the call to mkostemp() in ask_password_agent() is failing.

In that case, you should have an avc denial.
ausearch -i -m AVC,USER_AVC,SELINUX_ERR -ts today

If not, try this:
semodule -DB
Trigger the denial again.
ausearch -i -m AVC,USER_AVC,SELINUX_ERR -ts recent
semodule -B

OK so I have no idea why this wasn't showing up before, but I see there is one new AVC that was appearing, then stopped appearing, then has started again a few hours ago:

type=AVC msg=audit(1340106041.157:48401): avc:  denied  { search } for  pid=4866 comm="systemd-ask-pas" name="systemd" dev="tmpfs" ino=1944 scontext=system_u:system_r:httpd_passwd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir

and sure enough, adding this rule:

allow httpd_passwd_t init_var_run_t:dir search;

gets everything working...

Fixed in selinux-policy-3.10.0-133.fc17

selinux-policy-3.10.0-134.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-134.fc17

Package selinux-policy-3.10.0-134.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-134.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10008/selinux-policy-3.10.0-134.fc17
then log in and leave karma (feedback).

selinux-policy-3.10.0-134.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.