On Thu, 2007-11-29 at 16:32 -0500, Stephen Smalley wrote:
> On Thu, 2007-11-29 at 16:26 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi Stephen,
> >
> > Thanks as always for your response :-)
> >
> > I have already created a set of allow rules necessary. So we're using
> > SELinux is to capture info about EVERY attempt an unauthorized/rogue
> > user makes to access something they're NOT supposed to! So the reason I
> > want to see the DENY events in audit.log, is *NOT* for creating
> > corresponding allow rules.
> >
> > The "frequent periodic violation" I was referring to is as follows:
> >
> > type=AVC msg=audit(1196369398.427:126): avc: denied { read } for
> > pid=1040 com
> > m="klogd" name="kmsg" dev=proc ino=-268435446
> > scontext=system_u:system_r:kernel_
> > t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file
>
> So you never transitioned out of kernel_t (initial kernel task and
> kernel threads) into appropriate domains for userland (starting with a
> transition to init_t upon /sbin/init, init_exec_t). Normally klogd
> would run in klogd_t, and the above would be allowed by policy.
>
> > With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
> > audit.log every second ! I would like to create an allow rule, to get
> > rid of this event. When I used audit2allow to generate the allow rule, I
> > got:
> >
> > allow kernel_t proc_kmsg_t:file read
> >
> >
> > However, the base policy I am using as my starting policy is the
> > *STRICT* Fedora Core 6 policy. And with that in place, when I try to
> > insert this allow rule using (semodule -i myPolicy.pp), I get an
> > assertion failure for that allow rule!!! So seems like the base policy
> > wont let me insert this allow rule :-(
>
> Which is good, because it indicates a more fundamental problem - you've
> got a mislabeled klogd process.
>
> But suppose that wasn't the case and you truly wanted to allow that.
> Here is how you would do it:
> 1) Look for a refpolicy interface that grants access to kmsg. In a
> modern policy, that appears to be kernel_read_messages(). Then write
> your policy module using that interface, ala:
> $ vi myklogd.te
> policy_module(myklogd, 1.0)
> require {
> type kernel_t;
> }
> kernel_read_messages(kernel_t)
> :wq
> $ make -f /usr/share/selinux/devel/Makefile
> $ su
> # /usr/sbin/semodule -i myklogd.pp
>
> The refpolicy interface contains the 'magic' needed to override this
> assertion, namely adding an attribute to the kernel_t type. This
> ensures that you made a conscious decision to give access to this
> security-relevant resource and didn't accidentally do it via
> audit2allow.
>
> -or-
> 2) Disable assertion checking by libsemanage (not recommended, mostly
> for developers, but if you need it, it exists):
> $ su
> # vi /etc/selinux/semanage.conf
> :$
> i
> expand-check=0
> :wq
>
> > So that is my dilemma.
> > With cache_threshold = 0, I get all the denies I want to see. But I
> > also get these extra denies that I cant get rid off :-(
Also, it would be very simple to patch your kernel to not have this
behavior in permissive mode if you truly wanted that. Just look in
linux-2.6/security/selinux/avc.c in the avc_has_perm_noaudit() function,
and remove where it calls avc_update_node(AVC_CALLBACK_GRANT...). Then
it won't add those permissions to the cached entry, and it will keep
auditing them every time. I suppose we could make that
configurable/tunable in future kernels if there is a real demand for it.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
