Bug 185289

Created attachment 126029 [details]
proposed upstream patch

So I just verified this is broken in 2-6-9.34.0.1 and fixed in 2.6.9-39

First I added these rules to policy/test_exectrace.te

allow test_exectrace_parent_t initrc_devpts_t:chr_file { read write getattr };
allow test_exectrace_parent_t initrc_t:fd use;

allow test_exectrace_child_t initrc_devpts_t:chr_file { read write };
allow test_exectrace_child_t initrc_t:fd use;

allow test_exectrace_notchild_t initrc_devpts_t:chr_file { read write };
allow test_exectrace_notchild_t initrc_t:fd use;

which simply allow it to actually read and write to the ssh terminal.  Be sure
to run 'make -C $(LTPROOT)/testcases/kernel/security/selinux/policy load'

Next I patch selinux_exectrace_parent.c.   Being sure to run make and make install

Now run the test on an old kernel and you will get results like

[root@wbar1 tests]# ./runtest.sh exectrace
/root/ltp-full-20060615/testcases/kernel/security/selinux-testsuite/tests
Running with security context=root:system_r:unconfined_t
Run cat /proc/9107/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_child_t
..Resuming the child.
Child exited with status 0.
test01   PASS : exectrace passed.
Run cat /proc/9109/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_notchild_t
..Resuming the child.
Child exited with status 0.
test02   FAIL : exectrace failed.
Done.

Notice that the second test we are supposed to be tracing a child that we do not
have permissions to trace.  Yet it worked just fine!  Since the child trace
worked fine and exited with status 0 (success) the test failed.   This is bad. 
The child is supposed to fail which indicates the test passed.

Now on the new kernel we run the same tests

[root@test05-64 tests]# ./runtest.sh exectrace
/root/ltp-full-20060615/testcases/kernel/security/selinux-testsuite/tests
Running with security context=root:system_r:unconfined_t
Run cat /proc/3931/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_child_t
..Resuming the child.
Child exited with status 0.
test01   PASS : exectrace passed.
Run cat /proc/3969/environ in an unconfined shell and then hit return here.

Child terminated by signal 9.
..This is consistent with a ptrace permission denial - check the audit message.
test02   PASS : exectrace passed.
Done.

Notice in this case on the second test the child actually failed because of a
denial.  So the test passed.


I'm not sure what you saw happening, but using that test case I am able to
proove that this exploit is fixed.

After looking through some audit logs I had saved, I see what happened now.. due
to the policy problems you had pointed out.. evidently the parent wasn't even
being run (because the policy was denying it) and it was being interpreted as a
PASS. I don't think the LTP folks do much with the static policy anymore, looks
like all the work goes into refpolicy at this point which as far as I know we
can't use on RHEL 4. 

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0575.html