allow guest_u to access screen

[Lakshmipathi.G]

Thanks Dominikc for more detailed info.
Okay,will log the silent denials via semodule -DB option.

>not signal a bug and auditd (with the appropriate rules) can be used to
>log any specific syscalls.

How to do this? Logging specific syscall? Do we have another addition
feature like logging specific path (say /etc/passwd) ?


>many people see the policy as something that is fixed.
>If they have to write policy they argue that it is broken.

I understand the point, but the problem is at-least for users
like me, we are not really sure whether adding a new policy
may comprise on existing setup.

>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.

Yes,that's the main thing , to make SELinux customize to their requirement,
you need to a well experienced user,average users (like me) will rely on
tools like
audit2allow or audit2why etc,because these tools help him write a policy
without
really getting deep into the issue :D !


-- 
----
Cheers,
Lakshmipathi.G
FOSS Programmer.
www.giis.co.in
On Sun, Apr 14, 2013 at 10:30 PM, Dominick Grift
<dominick.grift at gmail.com>wrote:

> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20130416/dfb3bd30/attachment.html>