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

[Andy Lutomirski]

On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce <ssorce@xxxxxxxxxx> wrote:
> On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
>>
>> No.  The logging daemon thinks it wants to know who the writer is, but
>> the logging daemon is wrong.  It actually wants to know who composed a
>> log message destined to it.  The caller of write(2) may or may not be
>> the same entity.
>
> This works both ways, and doesn't really matter, you are *no* better off
> w/o this interface.
>
>> If this form of SO_PASSCGROUP somehow makes it into a pull request for
>> Linus, I will ask him not to pull it and/or to revert it.  I think
>> he'll agree that write(2) MUST NOT care who called it.
>
> And write() does not, there is no access control check being performed
> here. This call is the same as getting the pid of the process and
> crawling /proc with that information, just more efficient and race-free.

Doing it using the pid of writer is wrong.  So is doing it with the
cgroup of the writer.  The fact that it's even possible to use the pid
of the caller of write(2) is a mistake, but that particular mistake
is, unfortunately, well-enshrined in history.

>
> I repeat, it is *not* access control.
>

Sure it is.

Either correct attribution of logs doesn't matter, in which case it
makes little difference how you do it, or it does matter, in which
case it should be done right.

Here's a real world example from my industry.  Suppose I used journald
for logging on a production trading system.  The ability to write a
log line that says "I just bought 100000 EUR/USD for
such-and-such-price" attributed to a trading program is absolutely a
security-sensitive operation and must be subject to access control.

If Common Criteria doesn't say that audit logs need to be resistant to
spoofing, then that's just one more reason that Common Criteria is
broken.

I don't use journald for trading logs, and I'd be absolutely daft to
use ordinary syslog, because ordinary syslog doesn't even pretend to
be secure.  But if you're going to design something that claims to be
secure, "well, I can't see how this issue would be exploited" is not
good enough.

--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/