auditing kdbus service names

auditing kdbus service names

[Paul Moore]

Hello all,

I'm currently working on a set of LSM hooks for the new kdbus IPC mechanism 
and one of the things that I believe we will need to add is a new audit field 
for the kdbus service name (very similar to the old fashioned dbus service 
name).  I was thinking "kdbus_svc" for the field name, any objections?

-- 
paul moore
security @ redhat

Re: auditing kdbus service names

[Steve Grubb]

On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> Hello all,
> 
> I'm currently working on a set of LSM hooks for the new kdbus IPC mechanism
> and one of the things that I believe we will need to add is a new audit
> field for the kdbus service name (very similar to the old fashioned dbus
> service name).  I was thinking "kdbus_svc" for the field name, any
> objections?

What was used on the old dbus events?

-Steve

Re: auditing kdbus service names

[Paul Moore]

On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > Hello all,
> > 
> > I'm currently working on a set of LSM hooks for the new kdbus IPC
> > mechanism
> > and one of the things that I believe we will need to add is a new audit
> > field for the kdbus service name (very similar to the old fashioned dbus
> > service name).  I was thinking "kdbus_svc" for the field name, any
> > objections?
> 
> What was used on the old dbus events?

The very generic "service" field name, see the "acquire_svc" example in the 
URL below.  I believe there is some value in picking a new field name since 1) 
the field name is too generic in my opinion and 2) kdbus != dbus.

 * http://lists.freedesktop.org/archives/dbus/2004-November/001728.html

-- 
paul moore
security @ redhat

Re: auditing kdbus service names

[Steve Grubb]

On Wednesday, August 12, 2015 10:48:10 PM Paul Moore wrote:
> On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> > On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > > Hello all,
> > > 
> > > I'm currently working on a set of LSM hooks for the new kdbus IPC
> > > mechanism
> > > and one of the things that I believe we will need to add is a new audit
> > > field for the kdbus service name (very similar to the old fashioned dbus
> > > service name).  I was thinking "kdbus_svc" for the field name, any
> > > objections?
> > 
> > What was used on the old dbus events?
> 
> The very generic "service" field name, see the "acquire_svc" example in the
> URL below.  I believe there is some value in picking a new field name since
> 1) the field name is too generic in my opinion and 2) kdbus != dbus.

In my book, they are the same. They are programs providing services on the 
bus. One thing I noticed in the dbus events is that there are a number of user 
controlled fields that are not escaped.

Call it kdbus_svc if you want, but log it untrusted.

Thanks,
-Steve

Re: auditing kdbus service names

[Paul Moore]

On Thursday, August 13, 2015 04:40:52 PM Steve Grubb wrote:
> On Wednesday, August 12, 2015 10:48:10 PM Paul Moore wrote:
> > On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> > > On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > > > Hello all,
> > > > 
> > > > I'm currently working on a set of LSM hooks for the new kdbus IPC
> > > > mechanism and one of the things that I believe we will need to add is
> > > > a new audit field for the kdbus service name (very similar to the old
> > > > fashioned dbus service name).  I was thinking "kdbus_svc" for the
> > > > field name, any objections?
> > > 
> > > What was used on the old dbus events?
> > 
> > The very generic "service" field name, see the "acquire_svc" example in
> > the URL below.  I believe there is some value in picking a new field name
> > since 1) the field name is too generic in my opinion and 2) kdbus != dbus.
> 
> In my book, they are the same. They are programs providing services on the
> bus. One thing I noticed in the dbus events is that there are a number of
> user controlled fields that are not escaped.

Following up on this ...

Decided to just reuse "service" since the rest of the audit record will make 
it obvious (new obj class/perms) that the record if for a kdbus event and not 
a dbus event.  The next patchset will include the audit bits, I'll CC the 
patchset here.

-- 
paul moore
security @ redhat