Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path

[Andy Lutomirski]

On Wed, Apr 16, 2014 at 12:06 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
>> >
>> > [..]
>> >> > Ok, so passing cgroup information is not necessarily a problem as long
>> >> > as it is not used for authentication. So say somebody is just logging
>> >> > all the client request and which cgroup client was in, that should not
>> >> > be a problem.
>> >>
>> >> Do you consider correct attribution of logging messages to be
>> >> important?  If so, then this is a kind of authentication, albeit one
>> >> where the impact of screwing it up is a bit lower.
>> >
>> > So not passing cgroup information makes attribution more correct. Just
>> > logging of information is authentication how? Both kernel and user space
>> > log message into /var/log/messages and kernel messages are prefixed with
>> > "kernel". So this somehow becomes are sort of authentication. I don't
>> > get it.
>>
>> I did a bad job of explaining what I meant.
>>
>> I think that, currently, log lines can be correctly attributed to the
>> kernel or to userspace, but determining where in userspace a log line
>> came from is a bit flaky.  One of the goals of these patches is to
>> make log attribution less flaky.  But if you want log attribution to
>> be completely correct, even in the presence of malicious programs,
>> then I think that the current patches aren't quite there.
>
> Why do you think that current patches are not there yet in the presence of
> malicious program. In your example, one program opened the socket and
> passed it to malicious program. And all the future messages are coming
> from malicious program. As long as receiver checks for SO_PASSCGROUP,
> it covers your example.

This is backwards.  The malicious program opens the socket and passes
it to an unwitting non-malicious program.  That non-malicious program
sends messages, and the logging daemon things that the non-malicious
program actually intended for these messages to end up in the system
log.

>
>>
>> Is the reason that you don't want to modify the senders because you
>> want users of syslog(3) to get the new behavior?  If so, I think it
>> would be nice to update glibc to fix that, but maybe the kernel should
>> cooperate, and maybe SO_PEERCGROUP is a decent way to handle this.
>
> Modifying every user of unix sockets to start passing cgroup information
> will make sense only if it was deemed that passing cgroup information
> is risky inherently and should be done only in selected cases.
>
> I think so far our understanding is that we can't find anything
> inherently wrong with passing cgroup information, though there might
> be some corner cases we can run into and which are not obivious right
> now.

I think I've explained why causing write(2) to start transmitting the
caller's cgroup is problematic.  Your SO_PASSCGROUP patch does that.
Your SO_PEERCGROUP patch does not.

I'm still nervous about SO_PEERCGROUP and about a variant of
SO_PASSCGROUP that used the cgroup as of the time of connect(2), but
I'm much less convinced that there's an actual problem.  My
nervousness here is more that I don't like APIs that aren't clearly
safe.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/