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 cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
