On Thu, 2005-06-16 at 17:09 -0400, Security News wrote:
OK, what I'm trying to do now is to lock down a particular
directory,
so that only people in a certain role may use the files in that
directory. The best way I can see to do this is to have a user login
and the "newrole" their way into the new secure-area domain.
Here's what I have done thus far...
1) chcon -t securefiles_t /home/testuser/securefiles
2) I edited the policy/users file to allow certain users into a
"secureuser_r" role.
3) I edited policy/rbac to "allow user_r secureuser_r"
I created a file called policy/domains/misc/securefiles.te with the following:
<start .te file>
type secureuser_t, domain;
type securefiles_t, file_type;
role secureuser_r types secureuser_t;
allow secureuser_t securefiles_t:dir *;
allow secureuser_t securefiles:file *;
domain_auto_trans(user_t, newrole_exec_t, secureuser_t)
role_tty_type_change(user, secureuser)
allow newrole_t secureuser_t:process transition;
Use full_user_role(secureuser) to define your new role and domain.
Note that the domain_auto_trans rule above is wrong - you don't want
user_t to transition to your new user domain automatically upon running
newrole; you want it to transition to newrole_t as usual (and this will
be covered by full_user_role) and then have newrole explicitly
transition to the role specified by the user via the -r option.
You'll still need the securefiles_t type declaration and rules and the
role_tty_type_change() rule as well, but not the rest of the above.
Also, unless you truly want to allow all permissions, don't use *; use
one of the macros like create_file_perms and create_dir_perms (e.g. do
you really want to allow this domain to execute these files? To relabel
them? To mount on them? To be entered by executing these files?).
</end .te file>
I am able to comipile and load the policy, but when I login as
testuser and attempt to "newrole -r secureuser_r -t secureuser_t" my
terminal screen closes instantly.
My error log:
avc: denied {transition} for pid=4044 exe=/usr/bin/newrole
path=bin/bash ... scontext=testuser:user_r:newrole_t
tcontext=testuser:secureuser_r:secureuser_t
tclass=process
Looks like the newrole transition took precedence anyway. This denial
is being caused by policy/constraints, because you are attempting to
change roles and the new domain is not marked with a 'userdomain'
attribute. But this will be addressed automatically by using
full_user_role() above to define your user role and domain.
--
Stephen Smalley
National Security Agency