<div>Thanks Dominikc for more detailed info.</div><div>Okay,will log the silent denials via semodule -DB option.</div><div><br></div><div>>not signal a bug and auditd (with the appropriate rules) can be used to</div><div>
>log any specific syscalls.</div><div><br></div><div>How to do this? Logging specific syscall? Do we have another addition </div><div>feature like logging specific path (say /etc/passwd) ? </div><div><br></div><div><br>
</div><div>>many people see the policy as something that is fixed.</div><div>>If they have to write policy they argue that it is broken. </div><div><br></div><div>I understand the point, but the problem is at-least for users </div>
<div>like me, we are not really sure whether adding a new policy </div><div>may comprise on existing setup. </div><div><br></div><div>>But that requires that one learns to speak and write SELinuxs' language,</div>
<div>
>and that might be an intimidating prospect to some. Not to mention the</div><div>>ability to design a policy that meets ones requirements and to maintain</div><div>>that.</div><div><br></div><div>Yes,that's the main thing , to make SELinux customize to their requirement,</div>
<div>you need to a well experienced user,average users (like me) will rely on tools like </div><div>audit2allow or audit2why etc,because these tools help him write a policy without </div><div>really getting deep into the issue :D ! </div>
<div><br></div><br class="Apple-interchange-newline">-- <br>----<br>Cheers,<br>Lakshmipathi.G<br>FOSS Programmer.<br><a href="http://www.giis.co.in/" target="_blank">www.giis.co.in</a><br><div class="gmail_quote">On Sun, Apr 14, 2013 at 10:30 PM, Dominick Grift <span dir="ltr"><<a href="mailto:dominick.grift@gmail.com" target="_blank">dominick.grift@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sun, 2013-04-14 at 21:51 +0530, Lakshmipathi.G wrote:<br>
><br>
> To allow should be easy:<br>
><br>
> mkdir myguest; cd myguest<br>
> cat > myguest.te << EOF<br>
> policy_module(myguest, 1.0.0)<br>
> optional_policy(`<br>
> gen_require(` type guest_t; role guest_r; ')<br>
> screen_role_template(guest, guest_r, guest_t)<br>
> ')<br>
> EOF<br>
><br>
> make -f /usr/share/selinux/devel/Makefile myguest.pp<br>
> sudo semodule -i myguest.pp<br>
><br>
> This will allow guest_t to run screen in the guest_screen_t<br>
> domain.<br>
> You will probably want to relogin and run restorecon -R -v -F<br>
> ~/.screenrc<br>
><br>
><br>
><br>
> Added above policy it now 'guest_t' can use screen command. Thanks a<br>
> lot Dominick.<br>
><br>
<br>
</div></div>glad to hear.<br>
<br>
you did not see any avc denials earlier because selinux was instructed<br>
to silently deny attempts. you could expose these silent denials by<br>
running semodule -DB and then reproduce. This will load the policy with<br>
the " dontaudit" rules removed from the policy. (caution though that<br>
this may flood the logs especially with resticted users) To reinsert and<br>
reload the policy with the dontaudit rules , simply run semodule -B.<br>
<br>
The dontaudit rules are particualrly handy for restricted user domains.<br>
if users attempt t do things that they arent allowed to then avc denials<br>
are triggered. In some cases many of them. One does not always want to<br>
see those denials because in the case of users doing bad things, it does<br>
not signal a bug and auditd (with the appropriate rules) can be used to<br>
log any specific syscalls.<br>
<br>
guest_t is pretty much confined and was initially designed to be a<br>
minimal ssh login user domain. Through the years the guest user policy<br>
was adapted a bit for general use purposes (although usage of screen<br>
still did not fit that profile). But anyways, one would probably see<br>
many insignificant avc denials with the policy loaded without the<br>
dontaudit rules.<br>
<br>
Allowing guest_t access to run screen with a domain transition is not a<br>
security issue. However i would probably have cloned the existing guest<br>
policy module, renamed the clone and extended that to meet my personal<br>
requirements instead of extending the stock guest domain.<br>
<br>
Point is that SELinux is a framework that allows you to do all this. The<br>
idea is that one actually uses it to make it meet ones requirements.<br>
Instead however , many people see the policy as something that is fixed.<br>
If they have to write policy they argue that it is broken. To me that is<br>
a misconception.<br>
<br>
I would go actually further and say that the stock selinux policy is<br>
probably not a very optimal way to use selinux to secure ones systems.<br>
But then again, it is always better than no SELinux at all.<br>
<br>
What i am saying is that SELinux is best if you use it to create policy<br>
that meets your particular requirements. Just like i guess a firewall<br>
configuration would be better if it meets your requirements rather than<br>
a general purpose one-size-fits-all config.<br>
<br>
But that requires that one learns to speak and write SELinuxs' language,<br>
and that might be an intimidating prospect to some. Not to mention the<br>
ability to design a policy that meets ones requirements and to maintain<br>
that.<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>