Bug 128677 - avc denial while starting httpd + mod_ssl via ssh
Summary: avc denial while starting httpd + mod_ssl via ssh
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
Reported: 2004-07-27 20:41 UTC by Ben Levenson
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: 2.0.52-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-04 23:27:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ben Levenson 2004-07-27 20:41:21 UTC
Description of problem:
I received the following denail while restarting httpd over my ssh
connection to the server:
avc:  denied  { search } for  pid=7294 exe=/usr/sbin/httpd dev=devpts
ino=1 scontext=root:system_r:httpd_t tcontext=user_u:object_r:devpts_t

This is corrected with the following modification to policy:
allow httpd_t devpts_t:dir { search };

Version-Release number of selected component (if applicable):

Comment 1 Daniel Walsh 2004-07-28 14:50:00 UTC
Fixed in  selinux-policy-targeted-1.15.9-1

Comment 2 Ben Levenson 2004-07-28 16:38:55 UTC
dontaudit doesn't cut it in this case:

# rpm -q selinux-policy-targeted

# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: Apache/2.0.50 mod_ssl/2.0.50 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server test184.test.redhat.com:443 (RSA)
Enter pass phrase:Apache:mod_ssl:Error: Private key not found.

pushing back to ASSIGNED.

Comment 3 Daniel Walsh 2004-07-28 18:19:59 UTC
Could you remove the dontaudit and then run the start in permissive
mode.  I want to see the AVC messages.


Comment 4 Ben Levenson 2004-07-29 00:15:18 UTC
I still get just one AVC message after removing the dontaudit 
directive and switching to permissive mode:
avc:  denied  { search } for  pid=12049 exe=/usr/sbin/httpd dev=devpts
ino=1 scontext=root:system_r:httpd_t tcontext=user_u:object_r:devpts_t

Comment 5 Ben Levenson 2004-07-29 13:17:09 UTC
FWIW here is the resulting error message:
Starting httpd: Apache/2.0.50 mod_ssl/2.0.50 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server test184.test.redhat.com:443 (RSA)
Enter pass phrase:Apache:mod_ssl:Error: Private key not found.

Comment 6 Daniel Walsh 2004-07-29 17:10:15 UTC
If it breaks in Permissive mode than the problem is not SELinux

Comment 7 Ben Levenson 2004-07-29 17:48:03 UTC
I wasn't being very clear above.

* enforcing mode & allow httpd_t devpts_t:dir { search };
    httpd WILL start without error or AVC message

* enforcing mode & dontaudit httpd_t devpts_t:dir { search };
    httpd WILL NOT start and gives the error message in comment #5

* permissive mode & {allow,dontaudit} removed from apache.te
    httpd WILL start but gives the AVC message in comment #4 (this is
    100% reproducible after a policy reload)

Comment 8 Daniel Walsh 2004-09-09 18:29:59 UTC
Comment from Stephen Smalley...

Ok, so it wants to interact with user upon manual restart for a key?
How does it work when you boot the system - where does it get the
passphrase in that situation?

Comment 9 Ben Levenson 2004-09-09 19:07:15 UTC
The default behavior for this scenario requires the admin to type the
password during httpd startup at system boot.  I believe that it will
time out if nothing is entered, and the system will continue booting
without starting httpd.

I can ask nalin/jorton for information regarding the non-interactive
startup of httpd w/ mod_ssl.

Comment 10 Ben Levenson 2004-09-10 19:49:22 UTC
SSLPassPhraseDialog provides a non-interactive method to restart
I guess this is one possible workaround, but it doesn't solve the
issue as described above.

Comment 11 Brian Millett 2004-09-20 16:52:32 UTC
I also can not start httpd with ssl enabled.  I do not know if this is
related.  I have the target policy enabled.  This is the error message
I get:
Starting httpd: Syntax error on line 68 of /etc/httpd/conf.d/ssl.conf:
SSLRandomSeed: source path '/dev/urandom' does not exist

Ofcourse /dev/urandom exists.

If I set the 'transition->disable selinux protection for httpd' in the
system-config-securitylevel then httpd will start in ssl mode.

Comment 12 Stephen Smalley 2004-09-20 17:08:11 UTC
httpd_t is allowed access to /dev/urandom in the policy.  But the avc
messages you posted showed that your /dev was incorrectly labeled with
tmpfs_t.  Is your system up-to-date with the development tree, e.g.
kernel, udev, initscripts, policy all up-to-date?  Are you running
the Fedora kernel or a custom one?  

Comment 13 Brian Millett 2004-09-20 17:49:47 UTC
Yes, rawhide latest with the 2.6.8-1.549 kernel from arjan.  I had not
used SELinux at all and just turned it on.  I just noticed that there
is a newer kernel at arjan site, I will try that and see what happens.

Comment 14 Stephen Smalley 2004-09-20 17:58:40 UTC
I'm running -1.541 here without any problems, so you should have
the tmpfs xattr patch already.
/etc/rc.d/rc.sysinit restores the contexts on the /dev entries that
were created prior to initial policy load by udev run from the initrd.
Have you rebooted the system since you last updated initscripts?
If not, then you may still have a /dev that was never labeled, and
fixfiles won't touch it anymore since it is tmpfs.

Comment 15 Brian Millett 2004-09-20 18:19:45 UTC
Ok, just recently the dev package was removed.  Looks like the /dev is
regenerated by the udev package.  I had had the UDEV_INITRD="no" to
keep from seeing error messages at boot time.  With the new udev, I
changed it back to UDEV_INITRD="yes" and re created an initrd.
When I turned on selinux, I just used the securitylevel tool and
rebooted.  Do I need to relabel by hand as single user?

Going to -1.584 kernel did not solve the problem.

Comment 16 Stephen Smalley 2004-09-20 18:29:59 UTC
No, this should be handled by the restorecon commands executed by
/etc/rc.d/rc.sysinit on each boot (to restore the contexts on the dev
nodes created prior to initial policy load by udev from the initrd)
and then dynamically managed thereafter by udev itself.
Does your /etc/rc.d/rc.sysinit include the restorecon commands?
Originally added in 7.78-2, and still in 7.80-1.

What happens if you run 'restorecon /dev /dev/*' manually?

Comment 17 Brian Millett 2004-09-20 18:57:27 UTC
Yes it does:

if [ -x /sbin/restorecon ] && fgrep -q " /dev " /proc/mounts ; then
	/sbin/restorecon  /dev /dev/null
	/sbin/restorecon  /dev/* 2> /dev/null

I just rebooted into single user and noticed this:
/sbin/restorecon get context on /dev failed: 'Operation not supported'
/sbin/restorecon get context on /dev/null failed: 'Operation not

Do I need to do the /sbin/restorecon as single user? because all I get is:
restorecon get context on /dev failed: 'Operation not supported'
restorecon get context on /dev/adsp failed: 'Operation not supported'
restorecon get context on /dev/agpgart failed: 'Operation not supported'
restorecon get context on /dev/arpd failed: 'Operation not supported'
restorecon get context on /dev/audio failed: 'Operation not supported'
restorecon get context on /dev/audio1 failed: 'Operation not supported'
(many lines of same for each device)

Comment 18 Stephen Smalley 2004-09-20 19:03:56 UTC
No, restorecon works fine from multi-user mode.  Operation not
supported suggests that your kernel does lack the tmpfs xattr handlers.
Possibly Arjan's kernels (not necessarily the same as the Fedora
kernels) do not include this change, as he prefers to wait until
changes make it into the mainline kernel.  Fedora kernel has to carry
xattrs as a patch until the support is mainstreamed.

Comment 19 Brian Millett 2004-09-20 19:08:28 UTC
Ok.  Thanks.  Ill try to boot off of the kernel for FC3t2 and see.
Thanks for the help.  SELinux is a bit new to me.  Thanks for the

Comment 20 Brian Millett 2004-09-20 19:35:32 UTC
Ok, looks like the -1.541 is OK.  The kernels from Arjan lack the
xattr do not include this patch.  Nice to know.  I guess if you want
to test SELinux, then stick with the rawhide kernel.  I had thought
that Arjan's was a test of the fedora kernel.

Thanks alot.

Comment 21 Colin Walters 2004-11-03 18:24:59 UTC
It looks to me like we just need to have our default Apache
configuration use a SSLPassPhraseDialog program that simply reads from
/dev/tty.  Should be very simple to write such a program. 

Comment 22 Joe Orton 2004-11-03 20:16:32 UTC
OK, I'll do that.

Comment 23 Daniel Walsh 2004-11-03 20:23:56 UTC
That will fix it for targeted policy but not for strict.  What is the
name of the executable that is run which needs access to the terminal?

Comment 24 Joe Orton 2004-11-03 20:28:31 UTC
We can pick any name we want... I'll pick /usr/bin/htsslpass for want
of a better name.

Comment 25 Joe Orton 2004-11-08 22:31:41 UTC
Can you add the necessary bits for this to policy, Dan?

Comment 26 Joe Orton 2004-11-08 22:43:28 UTC
"necessary bits" being allowing httpd to execute /usr/bin/htsslpass
and for /usr/bin/htsslpass to be able to open "/dev/tty" for read and

Comment 29 Daniel Walsh 2004-11-16 17:30:15 UTC
Had to end up adding a tunable httpd_tty_comm that allows httpd to 
read write the terminal.

This will be off by default.

Fixed in selinux-policy-targeted-1.17.30-2.30

Comment 30 Colin Walters 2004-11-16 18:25:25 UTC
Hm, it doesn't work to allow apache to exec the htsslpass program?

Comment 31 Daniel Walsh 2004-11-16 18:30:32 UTC
It does exec the htsslpass program but it just hands it the TTY that
httpd was connected (/dev/null)

Comment 32 Stephen Smalley 2004-11-19 16:16:18 UTC
Remember that we changed SELinux to revalidate access to the process'
controlling tty (not just open descriptors to it) upon a
domain-changing exec (resetting it to NULL if access is denied) back
in August to prevent a process from always being able to re-acquire
access via /dev/tty.  Otherwise, a process could always re-accquire
access via /dev/tty if it was given permissions to devtty_t, because
the permission checks at the VFS layer are simply based on the
security context of the /dev/tty inode, not the inode of the real tty.
 Alternative would be to leave current->tty set but revalidate access
in the tty driver code upon opens of /dev/tty, but that would require
a hook in that driver code.

Hence, once SELinux revokes access to the controlling tty, it is truly
gone; you can't re-acquire it from a subsequent child running in a
different domain.  You need to instead run the interactive program
first in a domain with access to the tty, then transition to a daemon
domain that drops access.

Comment 33 Colin Walters 2004-11-20 04:05:30 UTC
Ah, I see.  I can't think of any particularly clever solutions in this
scenario then either.  I guess the boolean will have to do for now. 
But the solution of leaving current->tty set but revalidating later
does seem to be a more flexible solution; might that be considered at
a future point?

Comment 34 Ben Levenson 2004-11-22 21:35:55 UTC
Still receive the following denial:
avc:  denied  { search } for  pid=29252 exe=/usr/bin/htsslpass
dev=devpts ino=1 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:devpts_t tclass=dir

With the following packages:

Comment 35 Daniel Walsh 2004-11-22 21:45:24 UTC
setsebool -P httpd_tty_comm=1

Will fix it.  It is a boolean defaulting to off.

Comment 36 Ben Levenson 2004-11-22 21:56:34 UTC
I tested it after activating that boolean.

Comment 37 Joe Orton 2004-11-23 15:28:59 UTC
Argh.  So can we get this working out-of-the-box or at least
one-boolean-tweak-away for FC4/RHEL4?

With the latest RHEL4 tree:


out of the box with an encrypted SSL private key, httpd fails to start
, this is logged:

audit(1101223135.992:0): avc:  denied  { append } for  pid=3509
exe=/usr/bin/htsslpass path=/var/log/httpd/error_log dev=hda2
ino=1479816 scontext=root:system_r:httpd_helper_t
tcontext=user_u:object_r:httpd_runtime_t tclass=file

which seems to be add odds with what Ben saw.

If I switch to use the builtin tty prompt, and do:

# setsebool httpd_tty_comm 1

then I get the original problem back:

audit(1101223510.655:0): avc:  denied  { search } for  pid=3727
exe=/usr/sbin/httpd dev=devpts ino=1 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:devpts_t tclass=dir

If the htsslpass solution is actually not viable then I need to switch
the default configuration back to use the builtin tty prompt rather
than fork+exec-htsslpass.  And it's getting very late for default
config changes like this in RHEL4.  Let me know what to do.

Comment 38 Daniel Walsh 2004-11-23 15:36:00 UTC
Leave it the way it is, and I will fix the policy.  The policy needs
to be fixed whether you have your change or not, Since the user could
always make the change.


Comment 39 Stephen Smalley 2004-11-23 15:41:33 UTC
Explanatory note:  Kernel internally performs lookups on devpts root
directory when getting the pty, and this triggers a SELinux search
check.  So even if the application only does an open("/dev/tty"...),
this can still trigger a SELinux search check on /dev/pts because the
kernel internally does this lookup.

Comment 40 Joe Orton 2004-11-23 15:49:21 UTC
So is it possible to solve this by letting htsslpass have access to
/dev/tty but httpd not? I took Stephen's comment 32 to mean that this
was not possible.

If httpd itself must be granted tty access to solve this we might as
well remove htsslpass, it's just adding complexity.

Comment 41 Stephen Smalley 2004-11-23 16:09:39 UTC
Not possible for /dev/tty.  Possible for an explicit open of the real
tty, e.g. /dev/pts/0.  Or possible if you have a httpd front-end that
retains access, runs the helper, and then runs the real httpd that
drops access.

I'm a bit skeptical about getting a hook in the tty driver code, as
getting any hooks outside of the core kernel code was viewed as
improbable during LSM development.

Comment 42 Daniel Walsh 2004-11-23 20:05:35 UTC
Ok remove htsslpass to simplify, we will leave to policy so that if
users choose to use htsslpass or someother ssl helper it will work.


Comment 43 Joe Orton 2004-11-23 20:21:54 UTC
Dan, I can't parse that sentence.

The current issue this bug should track as far as I'm concerned, is that:

# setsebool httpd_tty_comm 1

does not work in that it never allows httpd to have /dev/tty access,
using package versions as above in comment 37.  This bug is in
MODIFIED state, yet I don't know which version of the policy package
has the fix for that boolean.

Are we on the same page?

Comment 44 Daniel Walsh 2004-11-23 20:56:46 UTC


Fixes the httpd_tty_comm problem.  

Comment 45 Joe Orton 2004-11-23 21:06:38 UTC
Thanks :) Can you let me know what versions get built for RHEL4 since
Raw Hide is otherwise broken for me at the mo.

Comment 46 Joe Orton 2004-11-24 14:41:40 UTC
Confirmed with;


that after running

# setsebool -P httpd_tty_comm=1

I can start httpd with an encrypted SSL key.

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