Stephen, thanks for your help.
Why I thought the restricted application was running with all the power
of an unconfined_t process is that the bentest script was:
#!/bin/sh
ps -Z
touch /usr/bentest/touched
touch /usr/touched
All the commands in this file succeeded. I expected them all to fail
(including the shell invocation itself), as I hadn't explicitly given
any "allow"s to bentest_t. The file contexts were:
/usr/bentest gen_context(system_u:object_r:bentest_t,s0)
/usr/bentest/bentest -- gen_context(system_u:object_r:bentest_exec_t,s0)
The system is running in enforcing mode according to "getenforce". The files were correctly labeled. I was running as root, but I expected that wouldn't matter.
I must be misunderstanding the fundamentals here. Any help you can give would be greatly appreciated.
Ben
On 12/20/05, Stephen Smalley <sds@tycho.nsa.gov> wrote:
On Mon, 2005-12-19 at 23:16 -0600, Benjamin Youngdahl wrote:
> I have a question on locking down an application under the targeted
> policy.
>
> The policy module I've tried is below. I can see that the process has
> the appropriate type in "ps -Z".:
>
> root:system_r:bentest_t:SystemLow-SystemHigh 13127 pts/1 00:00:00
> bentest
>
> But it still appears to have all the power of "unconfined_t". I did
> to a "restorecon -RF", and the files are appropriately labeled.
What makes you say it has all the power of unconfined_t?
> Is it possible for an app to confine "unconfined_t", or should I be
> switching over to the replacement for the strict policy? (I think it
> is just called "mls" at this point, which is a confusing name
> considering that targeted itself is an "mls" it seems.)
You should be able to confine a particular application under targeted
policy, just by putting it into its own domain, as you seem to be doing.
No need to switch to strict policy for that. MLS has a specific
meaning, not relevant here.
--
Stephen Smalley
National Security Agency