On Fri, 2013-03-29 at 09:45 -0400, m.roth@xxxxxxxxx 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@xxxxxxxxx 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@xxxxxxxxx wrote: > >>>>>>> Daniel J Walsh wrote: > >>>>>>>> On 03/26/2013 05:13 PM, m.roth@xxxxxxxxx wrote: > >>>>>>>>> m.roth@xxxxxxxxx wrote: > >>>>>>>>>> Daniel J Walsh wrote: > >>>>>>>>>>> On 03/26/2013 03:27 PM, m.roth@xxxxxxxxx wrote: > >>>>>>>>>>>> Daniel J Walsh wrote: > >>>>>>>>>>>>> On 03/26/2013 03:12 PM, m.roth@xxxxxxxxx wrote: > >>>>>>>>>>>>>> Daniel J Walsh wrote: > >>>>>>>>>>>>>>> On 03/26/2013 03:08 PM, m.roth@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
