On Sun, 2013-04-14 at 21:51 +0530, Lakshmipathi.G wrote: > > To allow should be easy: > > mkdir myguest; cd myguest > cat > myguest.te << EOF > policy_module(myguest, 1.0.0) > optional_policy(` > gen_require(` type guest_t; role guest_r; ') > screen_role_template(guest, guest_r, guest_t) > ') > EOF > > make -f /usr/share/selinux/devel/Makefile myguest.pp > sudo semodule -i myguest.pp > > This will allow guest_t to run screen in the guest_screen_t > domain. > You will probably want to relogin and run restorecon -R -v -F > ~/.screenrc > > > > Added above policy it now 'guest_t' can use screen command. Thanks a > lot Dominick. > glad to hear. you did not see any avc denials earlier because selinux was instructed to silently deny attempts. you could expose these silent denials by running semodule -DB and then reproduce. This will load the policy with the " dontaudit" rules removed from the policy. (caution though that this may flood the logs especially with resticted users) To reinsert and reload the policy with the dontaudit rules , simply run semodule -B. The dontaudit rules are particualrly handy for restricted user domains. if users attempt t do things that they arent allowed to then avc denials are triggered. In some cases many of them. One does not always want to see those denials because in the case of users doing bad things, it does not signal a bug and auditd (with the appropriate rules) can be used to log any specific syscalls. guest_t is pretty much confined and was initially designed to be a minimal ssh login user domain. Through the years the guest user policy was adapted a bit for general use purposes (although usage of screen still did not fit that profile). But anyways, one would probably see many insignificant avc denials with the policy loaded without the dontaudit rules. Allowing guest_t access to run screen with a domain transition is not a security issue. However i would probably have cloned the existing guest policy module, renamed the clone and extended that to meet my personal requirements instead of extending the stock guest domain. Point is that SELinux is a framework that allows you to do all this. The idea is that one actually uses it to make it meet ones requirements. Instead however , many people see the policy as something that is fixed. If they have to write policy they argue that it is broken. To me that is a misconception. I would go actually further and say that the stock selinux policy is probably not a very optimal way to use selinux to secure ones systems. But then again, it is always better than no SELinux at all. What i am saying is that SELinux is best if you use it to create policy that meets your particular requirements. Just like i guess a firewall configuration would be better if it meets your requirements rather than a general purpose one-size-fits-all config. But that requires that one learns to speak and write SELinuxs' language, and that might be an intimidating prospect to some. Not to mention the ability to design a policy that meets ones requirements and to maintain that. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
