On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce <sso...@redhat.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
