Ye olde "avc granted"

[Dominick Grift]

On Fri, 2013-03-29 at 09:45 -0400, m.roth at 5-cent.us wrote:
> Jean-David Beyer wrote:
> > On 03/28/2013 08:34 PM, mark wrote:
> >> On 03/28/13 19:39, Jean-David Beyer wrote:
> >>> On 03/28/2013 05:27 PM, m.roth at 5-cent.us wrote:
> >>>> Jean-David Beyer wrote:
> >>>>> On 03/27/2013 04:39 PM, Daniel J Walsh wrote:
> >>>>>> On 03/27/2013 04:25 PM, m.roth at 5-cent.us wrote:
> >>>>>>> Daniel J Walsh wrote:
> >>>>>>>> On 03/26/2013 05:13 PM, m.roth at 5-cent.us wrote:
> >>>>>>>>> m.roth at 5-cent.us wrote:
> >>>>>>>>>> Daniel J Walsh wrote:
> >>>>>>>>>>> On 03/26/2013 03:27 PM, m.roth at 5-cent.us wrote:
> >>>>>>>>>>>> Daniel J Walsh wrote:
> >>>>>>>>>>>>> On 03/26/2013 03:12 PM, m.roth at 5-cent.us wrote:
> >>>>>>>>>>>>>> Daniel J Walsh wrote:
> >>>>>>>>>>>>>>> On 03/26/2013 03:08 PM, m.roth at 5-cent.us wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Got a server that's throwing a ton of avc
> >>>>>>>>>>>>>>>> granted, all related to Matlab. I saw
> >>>>>>>>>>>>>>>> something via google from '06, for a java thing
> >>>>>>>>>>>>>>>> - is there something I can use to shut this
> >>>>>>>>>>>>>>>> up?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> CentOS 5.9, current.
> >>>>>>>>>>>> <snip>
> >>>>>>>>>>>>> One hack to fix this would be to turn the boolean
> >>>>>>>>>>>>> off and then write a custom policy module to allow
> >>>>>>>>>>>>> unconfined_t execheap.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> policy_module(myunconfined, 1.0) gen_require(` type
> >>>>>>>>>>>>> unconfined_t; ') allow unconfined_t self:process
> >>>>>>>>>>>>> execheap;
> >>>>>>>>>>>>
> >>>>>>>>> What a *pain*. As I said, I'm on CentOS 5.9, and rpm -qa |
> >>>>>>>>> grep selinux-policy\* selinux-policy-2.4.6-327.el5
> >>>>>>>>> selinux-policy-targeted-2.4.6-327.el5
> <snip>
> >>>>> It does in RHEL6
> >>>>
> >>>> Not in 5.9.
> >>>>
> >>> I do not have RHEL5.9, but I do have CentOS5.9 and it has it.
> >>> Are Red Hat and CentOS that different?
> >>
> >> Not at all: CentOS removed proprietary material, and recompiles from
> >> RHEL source. That is, in fact, what I'm running.
> >>
> > Then I do not understand why you said (unless I misunderstood) that this
> > was not in 5.9. Since it is in my 5.9, and I sure did not make a special
> > effort to get it because I do not even run SELinux on that machine.
> >
> > Where am I misunderstanding?
> 
> Was it you who mentioned selinux-policy-devel? At any rate, it's not
> installed.
> 
> Thing is, I'd really like to know what's wrong with my syntax, that I
> can't just use the same routine that I do when I get an output from
> audit2allow. There's *got* to be something I have missing.
> 

The issue is that there are two ways of writing policy. One is using raw
policy (writing it in a language that selinux understands( and one is
using human readable policy (an abstraction)

The policy_module() is a human readable way of declaring a policy
module. Its raw counterpart is "module $NAME $VERSION;"

The checkmodule utility can only work with the raw policy language, and
so it chokes on the human readable policy module declaration.

Basically the human readable policy abstraction layer was just built on
top of the existing infrastructure. So the old stuff doesnt know the new
stuff, but the new stuff does know the old stuff (e.g. you could use raw
policy with the refpolicy Makefile but you can't use human readable
policy with checkmodule)

It can be confusing

writing raw policy has it advantages/disadvantages just as writing human
readable policy.

raw policy gives one a bit more flexibility but it's often less
efficient and harder to maintain than human readable policy.

So if you write policy then you should first identify raw policy and
human readable policy, then consider that one cannot write/compile human
readable policy with the raw policy development utils (checkmodule) and
then you should be on your way.


>         mark
> 
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux