[permalink] [raw]

Hi,

this patchset against net-next (applies also to linux-next) adds 3 new types
of "Socket"-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP).

Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.

The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.

Changes introduced in this patchset can also increase performance
of such server-like processes, because current way of opening and
parsing /proc/$PID/* files is much more expensive than receiving these
metadata using SCM.

Changes in v4:
- Rebased to work with the latest net-next tree

Changes in v3:
- Better description of patches (Thanks to Kay Sievers)

Changes in v2:
- use PATH_MAX instead of PAGE_SIZE in SCM_CGROUP patch
- describe each patch individually

Jan Kaluza (3):
Send loginuid and sessionid in SCM_AUDIT
Send comm and cmdline in SCM_PROCINFO
Send cgroup_path in SCM_CGROUP

include/linux/socket.h | 9 ++++++
include/net/af_unix.h | 10 ++++++
include/net/scm.h | 67 ++++++++++++++++++++++++++++++++++++++--
net/core/scm.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
net/unix/af_unix.c | 70 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 237 insertions(+), 2 deletions(-)

--
1.8.3.1

2014-01-13 08:03:27

by Jan Kaluža

[permalink] [raw]

Subject: [PATCH v4 1/3] Send loginuid and sessionid in SCM_AUDIT

2014-01-13 08:03:36

by Jan Kaluža

[permalink] [raw]

2014-01-15 20:17:33

by David Miller

[permalink] [raw]

Subject: Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

From: Jan Kaluza <[email protected]>
Date: Mon, 13 Jan 2014 09:01:46 +0100

> Changes introduced in this patchset can also increase performance
> of such server-like processes, because current way of opening and
> parsing /proc/$PID/* files is much more expensive than receiving these
> metadata using SCM.

The problem with this line of reasoning is that these changes will
hurt everyone else, because these new control messages are sent
unconditionally, whether the application is interested in them or not.

I really don't like this cost tradeoff, it's terrible, and therefore
I'm really not inclined to apply these patches, sorry.

2014-01-15 23:21:57

by Eric Paris

[permalink] [raw]

Subject: Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

On Wed, 2014-01-15 at 12:17 -0800, David Miller wrote:
> From: Jan Kaluza <[email protected]>
> Date: Mon, 13 Jan 2014 09:01:46 +0100
>
> > Changes introduced in this patchset can also increase performance
> > of such server-like processes, because current way of opening and
> > parsing /proc/$PID/* files is much more expensive than receiving these
> > metadata using SCM.
>
> The problem with this line of reasoning is that these changes will
> hurt everyone else, because these new control messages are sent
> unconditionally, whether the application is interested in them or not.
>
> I really don't like this cost tradeoff, it's terrible, and therefore
> I'm really not inclined to apply these patches, sorry.

Agreed. Although you seem to be ignoring the part of the logic where is
solves a problem that can not be solved today.

> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.

Reliably being able to audit what process requested an action is
extremely useful. And I like the audit patch, as it is a couple of ints
we are storing.

procinfo and cgroup can both be up to 4k of data.

Is there an alternative he should consider? Some way to grab a
reference on task_struct and just attach that to the message?

2014-01-15 23:23:51

by Tejun Heo

[permalink] [raw]

Subject: Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

On Wed, Jan 15, 2014 at 06:21:43PM -0500, Eric Paris wrote:
> Reliably being able to audit what process requested an action is
> extremely useful. And I like the audit patch, as it is a couple of ints
> we are storing.
>
> procinfo and cgroup can both be up to 4k of data.
>
> Is there an alternative he should consider? Some way to grab a
> reference on task_struct and just attach that to the message?

Or maybe it can be made separately optional instead of tagging along
on an existing option so that it doesn't tax use cases which don't
care about the new stuff?

Thanks.

--
tejun

2014-01-16 09:30:09

by Jan Kaluža

[permalink] [raw]

Subject: Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

On 01/16/2014 12:23 AM, Tejun Heo wrote:
> On Wed, Jan 15, 2014 at 06:21:43PM -0500, Eric Paris wrote:
>> Reliably being able to audit what process requested an action is
>> extremely useful. And I like the audit patch, as it is a couple of ints
>> we are storing.
>>
>> procinfo and cgroup can both be up to 4k of data.
>>
>> Is there an alternative he should consider? Some way to grab a
>> reference on task_struct and just attach that to the message?
>
> Or maybe it can be made separately optional instead of tagging along
> on an existing option so that it doesn't tax use cases which don't
> care about the new stuff?

Right, I could add new option next to SOCK_PASSCRED which could be used
to send newly added stuff. Would this be acceptable?

I would still vote for SCM_AUDIT to be part of SOCK_PASSCRED and move
SCM_CGROUP and SCM_PROCINFO into new option.

> Thanks.
>

Regards,
Jan Kaluza

2014-01-23 19:31:47

by Kay Sievers

[permalink] [raw]

Subject: Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message

On Thu, Jan 16, 2014 at 10:29 AM, Jan Kaluža <[email protected]> wrote:
> On 01/16/2014 12:23 AM, Tejun Heo wrote:
>> On Wed, Jan 15, 2014 at 06:21:43PM -0500, Eric Paris wrote:
>>>
>>> Reliably being able to audit what process requested an action is
>>> extremely useful. And I like the audit patch, as it is a couple of ints
>>> we are storing.
>>>
>>> procinfo and cgroup can both be up to 4k of data.
>>>
>>> Is there an alternative he should consider? Some way to grab a
>>> reference on task_struct and just attach that to the message?
>>
>> Or maybe it can be made separately optional instead of tagging along
>> on an existing option so that it doesn't tax use cases which don't
>> care about the new stuff?
>
> Right, I could add new option next to SOCK_PASSCRED which could be used to
> send newly added stuff. Would this be acceptable?
>
> I would still vote for SCM_AUDIT to be part of SOCK_PASSCRED and move
> SCM_CGROUP and SCM_PROCINFO into new option.

Maybe we could just add a new SOCK_PASS_TASKINFO bit to set in
socket->flags. Set that bit with a new SO_PASS_TASKINFO sockoption.

The SOCK_PASS_TASKINFO can carry all sorts of "struct task" related
stuff, also include the audit data. It is all fully conditional, so
users which do not explicitly subscribe to TASKINFO will never see the
data or needlessly pay for the overhead.

A TASKINFO sounds generic enough to be possibly extended with new data
in the future, without wasting extra bits in the socket flags.

Users which subscribe with SO_PASS_TASKINFO expect some overhead
anyway. In the end it's still a lot cheaper than parsing /proc for the
data; which is also racy and does therefore not work for any
short-living program.

Thanks,
Kay