auditing kdbus service names
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?
Signature · 2 lines
paul moore security @ redhat
Quoted 7 lines · 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?
What was used on the old dbus events?
-Steve
Quoted 11 lines · Steve Grubb
Quoted 8 lines · 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?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
Signature · 2 lines
paul moore security @ redhat
Quoted 11 lines · Paul Moore
Quoted 10 lines · Steve Grubb
Quoted 8 lines · 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?
Quoted 5 lines
Quoted 1 line
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
Quoted 13 lines · Steve Grubb
Quoted 12 lines · Paul Moore
Quoted 10 lines · Steve Grubb
Quoted 7 lines · 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?What was used on the old dbus events?
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
paul moore security @ redhat
Quoted 7 lines · 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,
really great news.
Thx.
Signature · 3 lines
Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.