* auditing kdbus service names
@ 2015-08-12 12:40 Paul Moore
2015-08-12 21:38 ` Steve Grubb
2015-08-18 15:15 ` Miroslav Grepl
0 siblings, 2 replies; 10+ messages in thread
From: Paul Moore @ 2015-08-12 12:40 UTC (permalink / raw)
To: linux-audit; +Cc: Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
2015-08-12 12:40 auditing kdbus service names Paul Moore
@ 2015-08-12 21:38 ` Steve Grubb
2015-08-18 15:15 ` Miroslav Grepl
1 sibling, 0 replies; 10+ messages in thread
From: Steve Grubb @ 2015-08-12 21:38 UTC (permalink / raw)
To: linux-audit; +Cc: Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
@ 2015-08-12 21:38 ` Steve Grubb
0 siblings, 0 replies; 10+ messages in thread
From: Steve Grubb @ 2015-08-12 21:38 UTC (permalink / raw)
To: linux-audit; +Cc: Paul Moore, Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
2015-08-12 21:38 ` Steve Grubb
@ 2015-08-13 2:48 ` Paul Moore
-1 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2015-08-13 2:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: Paul Osmialowski, linux-security-module, linux-audit, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
@ 2015-08-13 2:48 ` Paul Moore
0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2015-08-13 2:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
2015-08-13 2:48 ` Paul Moore
@ 2015-08-13 20:40 ` Steve Grubb
-1 siblings, 0 replies; 10+ messages in thread
From: Steve Grubb @ 2015-08-13 20:40 UTC (permalink / raw)
To: Paul Moore; +Cc: Paul Osmialowski, linux-security-module, linux-audit, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
@ 2015-08-13 20:40 ` Steve Grubb
0 siblings, 0 replies; 10+ messages in thread
From: Steve Grubb @ 2015-08-13 20:40 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
2015-08-13 20:40 ` Steve Grubb
@ 2015-10-01 22:32 ` Paul Moore
-1 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2015-10-01 22:32 UTC (permalink / raw)
To: Steve Grubb; +Cc: Paul Osmialowski, linux-security-module, linux-audit, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
@ 2015-10-01 22:32 ` Paul Moore
0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2015-10-01 22:32 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, Paul Osmialowski, linux-security-module, selinux
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: auditing kdbus service names
2015-08-12 12:40 auditing kdbus service names Paul Moore
2015-08-12 21:38 ` Steve Grubb
@ 2015-08-18 15:15 ` Miroslav Grepl
1 sibling, 0 replies; 10+ messages in thread
From: Miroslav Grepl @ 2015-08-18 15:15 UTC (permalink / raw)
To: selinux, pmo >> Paul Moore
On 08/12/2015 02:40 PM, 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?
>
Paul,
really great news.
Thx.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-01 22:32 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-12 12:40 auditing kdbus service names Paul Moore
2015-08-12 21:38 ` Steve Grubb
2015-08-12 21:38 ` Steve Grubb
2015-08-13 2:48 ` Paul Moore
2015-08-13 2:48 ` Paul Moore
2015-08-13 20:40 ` Steve Grubb
2015-08-13 20:40 ` Steve Grubb
2015-10-01 22:32 ` Paul Moore
2015-10-01 22:32 ` Paul Moore
2015-08-18 15:15 ` Miroslav Grepl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.