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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 16, 2014 at 12:39 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Wed, Apr 16, 2014 at 12:13:21PM -0700, Andy Lutomirski wrote:
>> 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.
>
> Either way you look at it, I can't see the problem. Even without cgroup
> info, in your example, a non-malicious programs error message will show
> up at the receiver (Because malicious program passed that fd as stdout
> to non-malicious program).
>
> Are you complainig about this?
>
> Or are you complaing that non-malicious program's cgroup info will show
> up at the receiver. What's the problem with that. Receiver can use
> SO_PASSCGROUP and get non-malicious programs cgroup and log it (along
> with error message). I don't see where is the problem in that.

I'm not talking about the risk that someone learns someone's cgroup.
I'm talking about the risk that a malicious program can get a lot
entry like: "whatever planted text"
_SYSTEMD_UNIT=non-malicious.service.  That is, they've spoofed a log
line.

If you don't care about spoofing of log lines, then there's no point
to having the kernel validate them anyway.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Discussion]     [TCP Instrumentation]     [Ethernet Bridging]     [Linux Wireless Networking]     [Linux WPAN Networking]     [Linux Host AP]     [Linux WPAN Networking]     [Linux Bluetooth Networking]     [Linux ATH6KL Networking]     [Linux Networking Users]     [Linux Coverity]     [VLAN]     [Git]     [IETF Annouce]     [Linux Assembly]     [Security]     [Bugtraq]     [Yosemite Information]     [MIPS Linux]     [ARM Linux Kernel]     [ARM Linux]     [Linux Virtualization]     [Linux IDE]     [Linux RAID]     [Linux SCSI]