One and all,
My apologies for crashing in on this thread and for asking something a bit off topic from SELinux specific to Linux auditing in general.
I am trying to compile a list of (Fedora/RHEL) Linux audit_event information and I am wondering it this has been done before and where I may find it.
We are trying to document/compile Linux audit configuration information and a catalog of events for these configs.
Can anyone help point me to a list of all the Linux audit_events, descriptions, id numbers, etc.?
Your help is greatly appreciated.
Bryan Kropf, CISSP, NSA-IAM/IEM
Raytheon Systems Engineering
443 445-8936 (Office)
Bryan_Kropf@xxxxxxxxxxxx
To: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
From: "Christopher J. PeBenito" <cpebenito@xxxxxxxxxx>
Sent by: owner-selinux@xxxxxxxxxxxxx
Date: 05/19/2010 01:49PM
cc: Stephen Smalley <sds@xxxxxxxxxxxxx>, Shaz <shazalive@xxxxxxxxx>, TaurusHarry <harrytaurus2002@xxxxxxxxxxx>, dwalsh@xxxxxxxxxx, selinux-mailing-list <selinux@xxxxxxxxxxxxx>
Subject: Re: How to cross install policy store?
On Wed, 2010-05-19 at 09:01 -0700, Justin P. Mattock wrote:
> On 05/19/2010 07:39 AM, Stephen Smalley wrote:
> > On Wed, 2010-05-19 at 07:18 -0700, Justin P. Mattock wrote:
> >> On 05/19/2010 06:34 AM, Stephen Smalley wrote:
> >>> On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
> >>>> On 05/19/2010 03:04 AM, Shaz wrote:
> >>>>>> It's very true that both SELInux policy and policy store are
> >>>>>> arch-independent. It takes about 70 minutes to build the policy store from
> >>>>>> scratch on my embedded target, but I could copy and use the host policy
> >>>>>> store on the target, only that it will take 20 minutes each time to change
> >>>>>> SELinux attribute on the fly by the semanage tool, so I think I'd better
> >>>>>> save all the trouble by committing the changes to SELInux source code on the
> >>>>>> host instead.
> >>>>>
> >>>>> Sounds interesting. Let me try it too.
> >>>>>
> >>>>
> >>>>
> >>>> yep.. I built a policy on x86_64
> >>>> then copied it to all my other machines(i586)
> >>>> (no problem), but things like libselinux
> >>>> will probably be a different story.
> >>>
> >>> Well, yes, because libselinux is executable code. policy is just data.
> >>>
> >>
> >>
> >> hmm.. I'm wondering if something could be modified
> >> with monolithic policies and the whole policy
> >> version thing i.g. build.conf:
> >>
> >> # Policy version
> >> # By default, checkpolicy will create the highest
> >> # version policy it supports. Setting this will
> >> # override the version. This only has an
> >> # effect for monolithic policies.
> >> #OUTPUT_POLICY = 18
> >
> > I'm not sure what you're asking, but I did mention setting OUTPUT_POLICY
> > in build.conf or policy-version in semanage.conf to force generation of
> > an older version of policy when building on a host that supports a newer
> > policy version than the target system.
> >
>
> I was just wondering if this mechanism is a bit ancient,
> since it only applies to monolithic(that's all).
As long as the toolchain supports building monolithic policies and
optionally setting a specific policy version, I see no reason to remove
it. I still do tests of monolithic refpolicy to ensure it builds.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
--
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.
