Red Hat Bugzilla – Bug 218500
LSPP: tkill and tgkill are allowed to kill lower level processes
Last modified: 2007-11-30 17:07:38 EST
Description of problem:
The tkill and tgkill operations allow killing a process that is of lower level
than the subject. This is against the BLP model.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a simple infinite loop script #!/bin/sh while true; do a=1; done in
file called test.sh
2. chmod +x test.sh
3. chcon -l s0 test.sh
4. newrole -l s1
5. build and execute supplied testcase which execs test.sh and then attempts to
kill it with tkill. To test tgkill change the comment in the test from the
tgkill line to the tkill line.
Able to kill the process
Shouldn't be able to kill the process.
Created attachment 142880 [details]
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Not a bug as far as I can see.
You created a shell process at s1 via newrole.
Then you ran your test program (stays in s1).
The test program forks and exec's test.sh (stays in s1 - the level of a file
does not influence the level of the running process, although naturally the
process must be able to read/execute the file).
The parent process of the test program tries to kill the child process (both in s1).
You need to start test.sh from the s0 shell, then newrole to s1 and invoke kill
with the pid of the test.sh process.
For reference, see the sigkill test in the selinux testsuite, although that
naturally differs in that it deals with domains (types) rather than levels and
it uses runcon rather than newrole (which might not be feasible without a more
permissive policy for testing).
BTW, if MLS/BLP worked the way the testcase seems to think it does (i.e. that a
s0 file triggers a transition to s0 for the running process), then the mere
ability to exec test.sh from the s1 process would be a violation of MLS/BLP,
because that would be a s1->s0 information flow. Fortunately, that isn't how
MLS/BLP works. As far as MLS is concerned, the only question is whether the s1
process can read the s0 script, which of course it can (read down is fine).
I agree with this explanation that the bug is in my testcase.