Bug 128677

Fixed in  selinux-policy-targeted-1.15.9-1

dontaudit doesn't cut it in this case:

# rpm -q selinux-policy-targeted
selinux-policy-targeted-1.15.9-1

# 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.
**Stopped
                                                           [FAILED]

pushing back to ASSIGNED.

Could you remove the dontaudit and then run the start in permissive
mode.  I want to see the AVC messages.

Dan

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
tclass=dir

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.
**Stopped
                                                           [FAILED]

If it breaks in Permissive mode than the problem is not SELinux

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 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?

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.

SSLPassPhraseDialog provides a non-interactive method to restart
httpd. 
http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslpassphrasedialog
I guess this is one possible workaround, but it doesn't solve the
issue as described above.

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.

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?  

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.

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.

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.

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?

Yes it does:

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

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
supported'

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)

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
tmpfs
xattrs as a patch until the support is mainstreamed.

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
patience.

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.

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. 

OK, I'll do that.

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?

We can pick any name we want... I'll pick /usr/bin/htsslpass for want
of a better name.

Can you add the necessary bits for this to policy, Dan?

"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
write.

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
and
selinux-policy-targeted-1.19.1-10

Hm, it doesn't work to allow apache to exec the htsslpass program?

It does exec the htsslpass program but it just hands it the TTY that
httpd was connected (/dev/null)

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.

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?

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:
selinux-policy-targeted-1.19.4-1.noarch
system-config-securitylevel-1.4.18-1.x86_64
libselinux-1.19.1-6.x86_64

setsebool -P httpd_tty_comm=1

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

I tested it after activating that boolean.

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:

httpd-2.0.52-7.ent
selinux-policy-targeted-1.17.30-2.32
libselinux-1.17.14-1

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.

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.

Dan

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.

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.

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.

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.

Dan

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?

Sorry,

selinux-policy-targeted-1.17.30-2.34 
selinux-policy-*-1.19.4-4 

Fixes the httpd_tty_comm problem.  

Thanks :) Can you let me know what versions get built for RHEL4 since
Raw Hide is otherwise broken for me at the mo.

Confirmed with;

httpd-2.0.52-8.ent
selinux-policy-targeted-1.17.30-2.35

that after running

# setsebool -P httpd_tty_comm=1

I can start httpd with an encrypted SSL key.