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@xxxxxxxxx> wrote:
glad to hear.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.
>
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
