audisp plugin policy question(s)

audisp plugin policy question(s)

[LC Bruzenak]

In the audisp plugin sources (and audit.spec), the zos-remote plugin has
a policy section, the others do not. Will those pieces be added
similarly? Should prelude/prelude-plugin/remote-plugin policy go here or
in the system policy rpm?

Also some MLS prelude-related questions:

I realize this is technically a prelude policy question vice audit, but
I'm not certain how many selinux/MLS folks are on that list. Dan Walsh
suggested I ask on this list first. And it is due to the prelude plugin
to audit that this comes up, so at least the plugin is germane.

Right now my prelude-manager runs ranged SystemLow-SystemHigh.
Should this be only SystemHigh? I'm not exactly certain how this is done
now to run ranged. Here is the process listing:
ps -edaflZ | grep prelude
system_u:system_r:prelude_t:SystemLow-SystemHigh 1 S root 2432 1  0 80 0 - 33187 epoll_ Oct20 ?   00:00:04 prelude-manager -d
system_u:system_r:prelude_audisp_t:SystemHigh 0 S root 2664 2662  0 76 -4 - 10392 unix_s Oct20 ?  00:00:03 /sbin/audisp-prelude

There are some spool files not set accordingly which cause AVCs.
I guess these need file contexts?

As I said, there are many AVCs and those can probably be eliminated with
audit2allow exercises and review of the issue (like the labels on the
spool files).

Then there is a prelude-manager<->prelude-lml question, but I won't get
into that in case I hear "take it up with the prelude guys" from the
above.

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: audisp plugin policy question(s)

[Steve Grubb]

On Wednesday 22 October 2008 12:46:24 LC Bruzenak wrote:
> In the audisp plugin sources (and audit.spec), the zos-remote plugin has
> a policy section, the others do not. Will those pieces be added
> similarly? Should prelude/prelude-plugin/remote-plugin policy go here or
> in the system policy rpm?

No. I removed SE Linux policy in this commit last week:

https://fedorahosted.org/audit/changeset/134


> Right now my prelude-manager runs ranged SystemLow-SystemHigh.
> Should this be only SystemHigh?

I would put the prelude manager and correlator at the same level as the audit 
daemon since they get parts of the audit logs in events. So, if auditd is 
ranged, prelude should be.


> There are some spool files not set accordingly which cause AVCs.
> I guess these need file contexts?

Yep. Those spools are likely storage for transmissions while prelude-manager 
is down.


> Then there is a prelude-manager<->prelude-lml question, but I won't get
> into that in case I hear "take it up with the prelude guys" from the
> above.

I would take it up with them iff you have a reproducable problem when not in 
MLS. If its only shows up when on MLS, you likely have a policy problem.

-Steve

Re: audisp plugin policy question(s)

[LC Bruzenak]

On Wed, 2008-10-22 at 12:53 -0400, Steve Grubb wrote:
> On Wednesday 22 October 2008 12:46:24 LC Bruzenak wrote:
> 
> 
Steve,

Thanks for the info!

> > Right now my prelude-manager runs ranged SystemLow-SystemHigh.
> > Should this be only SystemHigh?
> 
> I would put the prelude manager and correlator at the same level as the audit 
> daemon since they get parts of the audit logs in events. So, if auditd is 
> ranged, prelude should be.

The auditd runs syshi, so that means the prelude-manager should be
changed. 
I'll run the correlator on a non-mls policy system where I aggregate all
audit data, so that one doesn't affect me (I think).

system_u:system_r:auditd_t:SystemHigh 5 S root 2660    1  0  76  -4 - 28177 epoll_ Oct20 ?        00:00:02 auditd

> 
> > There are some spool files not set accordingly which cause AVCs.
> > I guess these need file contexts?
> 
> Yep. Those spools are likely storage for transmissions while prelude-manager 
> is down.
> 
I think you are right.

I set those manually (with chcon) and the access AVCs were gone, but
they need to be made permanent in policy.

These subdirs/files are all under /var/spool/prelude
and /var/spool/prelude-manager. 

> 
> > Then there is a prelude-manager<->prelude-lml question, but I won't get
> > into that in case I hear "take it up with the prelude guys" from the
> > above.
> 
> I would take it up with them iff you have a reproducable problem when not in 
> MLS. If its only shows up when on MLS, you likely have a policy problem.

Then it's policy (or configuration). On my non-mls machine it is fine.

Here's the issue: 

Setup 1: Have a prelude_lml listening on each level for router syslogs.
----------------     
|  MLS server  |
| s1.s15:\     |
| c0.c1023     |
|              |
| prelude-mgr  |
|              |
|prelude_lml_1 |<------> (router1) WAN1 level s4:c3.c5
|prelude_lml_2 |<------> (router2) WAN2 level s14:c0.c1022
----------------
Then the lower-level prelude-lmls would need policy to talk to the syshi
prelude-manager. A more paranoid approach would be to also launch
prelude-managers at those levels in addition to the syshi one.

Setup 2: Make the prelude_lml be ranged, listening on both nets:
----------------     
|  MLS server  |
| s1.s15:\     |
| c0.c1023     |
|              |
| prelude-mgr  |
|              |
| prelude_lml  |<------> (router1) WAN1 level s4:c3.c5
|              |<------> (router2) WAN2 level s14:c0.c1022
----------------

In this case the same prelude-lml would listen on both nets. 
>From a security perspective it is possible for it to transfer data
directly from one to the other; however given the data is only router
logs this probably be acceptable IMO. 

In either case there is a risk that the prelude-manager could send
higher-classified data through the prelude-lml that I do not think we
can abate easily with policy, since it probably needs bidirectional data
to operate normally.

Thanks again!
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com