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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrU9P+1Az+uuU_zE4uZZ-qmp5M_=YAXvfcK=rzQRbgoG5g@mail.gmail.com>
Date:	Wed, 16 Apr 2014 13:24:32 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Simo Sorce <ssorce@...hat.com>, David Miller <davem@...emloft.net>,
	Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	lpoetter@...hat.com, cgroups@...r.kernel.org, kay@...hat.com,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path

On Wed, Apr 16, 2014 at 12:39 PM, Vivek Goyal <vgoyal@...hat.com> 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@...hat.com> 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@...hat.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/