net: Implement SO_PEERCGROUP and SO_PASSCGROUP socket options

Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the cgroup of first mounted hierarchy of the task. For the case of client, it represents the cgroup of client at the time of opening the connection. After that client cgroup might change.

This works only for unix stream sockets.

Quoted 6 lines · Vivek Goyal

Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the cgroup of first mounted hierarchy of the task. For the case of client, it represents the cgroup of client at the time of opening the connection. After that client cgroup might change.

This works only for unix stream sockets.

I still don't understand why this is useful when SCM_CGROUP exists.

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

--Andy

Quoted 14 lines · Vivek Goyal

Quoted 13 lines

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 7 lines

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it.

And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received.

Quoted 14 lines · Andy Lutomirski

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 7 lines

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it.

And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received.

Quoted 24 lines · Vivek Goyal

Quoted 14 lines · Andy Lutomirski

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 7 lines

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

Quoted 6 lines

How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it.

And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received.

I think the kernel should validate the data.

Here's an attack against SO_PEERCGROUP: if you create a container with a super secret name, then every time you connect to any unix socket, you leak the name.

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

I advocate for the following semantics: if sendmsg is passed a SCM_CGROUP cmsg, and that cmsg has the right cgroup, and the receiver has SO_PASSCGROUP set, then the receiver gets SCM_CGROUP. If you try to lie using SCM_CGROUP, you get -EPERM. If you set SO_PASSCGROUP, but your peer doesn't sent SCM_CREDS, you get nothing.

This is immune to both attacks. It should be cheaper, too, since there's no overhead for people who don't use it.

Quoted 34 lines · Andy Lutomirski

Quoted 24 lines · Vivek Goyal

Quoted 14 lines · Andy Lutomirski

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 7 lines

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

Quoted 6 lines

How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it.

And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received.

I think the kernel should validate the data.

Quoted 3 lines

Here's an attack against SO_PEERCGROUP: if you create a container with a super secret name, then every time you connect to any unix socket, you leak the name.

One should be able to do that already today with SO_PASSCRED option and then map pid to cgroup. Or if one is using user namespaces then go through uid mappings and figure out which container sent message.

Quoted 5 lines

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

If you can get another process to write to your socket and impersonate, then what will stop from that process to also send SCM_CGROUP message also? So I don't see how SCM_CGROUP from client will solve this problem.

Kernel cgroup verification will also not help in this case as sender is sending his own cgroup.

Quoted 10 lines

I advocate for the following semantics: if sendmsg is passed a SCM_CGROUP cmsg, and that cmsg has the right cgroup, and the receiver has SO_PASSCGROUP set, then the receiver gets SCM_CGROUP. If you try to lie using SCM_CGROUP, you get -EPERM. If you set SO_PASSCGROUP, but your peer doesn't sent SCM_CREDS, you get nothing.

This is immune to both attacks. It should be cheaper, too, since there's no overhead for people who don't use it.

I think you seem to be saying that a client's credentials should not be visible to receiver until and unless client himself wants to reveal those. IOW, it kind of looks like an anonymous mode of operation where client connects to a socket but receiver client not want to reveal any of the information about itself to receiver.

I am not sure how useful that mode really is. If it is really useful, I think one could implement another socket option on client side to deny passing cgroup information to receiver. Say SO_NOPASSCGROUP.

Before we even get there, I will question that what's so secret about cgroup information that one would like to hide it from receiver. We don't hide uid, pid, gid.

Secondly, how would client know when to send SCM_CGROUP to receiver. For the use case I mentioned that init wants to log cgroup of every message going into journal. How would client know that every message needs to have SCM_CGROUP. By automatically getting client information when receiver needs it, simplifies the things a lot without any client modificaiton.

Quoted 39 lines · Vivek Goyal

Quoted 37 lines · Andy Lutomirski

Quoted 24 lines · Vivek Goyal

Quoted 14 lines · Andy Lutomirski

Quoted 13 lines · Vivek Goyal

This patch implements socket option SO_PASSCGROUP along the lines of SO_PASSCRED.

If SO_PASSCGROUP is set, then recvmsg() will get a control message SCM_CGROUP which will contain the cgroup path of sender. This cgroup belongs to first mounted hierarchy in the sytem.

SCM_CGROUP control message can only be received and sender can not send a SCM_CGROUP message. Kernel automatically generates one if receiver chooses to receive one.

This works both for unix stream and datagram sockets.

Quoted 7 lines

Quoted 3 lines

cgroup information is passed only if either the sender or receiver has SO_PASSCGROUP option set. This means for existing workloads they should not see any significant performance impact of this change.

This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to sendmsg?

Quoted 6 lines

How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it.

And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received.

I think the kernel should validate the data.

Here's an attack against SO_PEERCGROUP: if you create a container with a super secret name, then every time you connect to any unix socket, you leak the name.

Quoted 3 lines

One should be able to do that already today with SO_PASSCRED option and then map pid to cgroup. Or if one is using user namespaces then go through uid mappings and figure out which container sent message.

Not if you've locked down proc, perhaps by using hidepid.

Quoted 10 lines

Quoted 5 lines

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

If you can get another process to write to your socket and impersonate, then what will stop from that process to also send SCM_CGROUP message also? So I don't see how SCM_CGROUP from client will solve this problem.

I can easily get other processed to write to my socket. Passing that socket as stderr to a setuid program is probably the easiest way. Finding a service that accepts a socket using SCM_RIGHTS and writes to it is another. It is supposed to be safe to write(2) to an untrusted file descriptor, or, at the very least, it is supposed to be a DoS at worst. In this case, it's also either an information leak.

It's true that SO_PASSCRED has the same problem. I consider that to be a mistake, and I suspect that there are a large number of longstanding security problems caused by it. Regardless, we shouldn't exacerbate this problem. There is no legacy code using SCM_CGROUP at all right now, because the option has never been in a released kernel.
So let's get the interface right the first time around.

If I find some time later today, I can try to write a variant of the patch that only sends SCM_CGROUP when the sender requests it.

On an unrelated note, what happens when there are multiple cgroup hierarchies?

Quoted 2 lines

Kernel cgroup verification will also not help in this case as sender is sending his own cgroup.

Sure it will -- the sender sticks a string into SCM_CGROUP and the kernel checks it.

Quoted 18 lines

Quoted 11 lines

I advocate for the following semantics: if sendmsg is passed a SCM_CGROUP cmsg, and that cmsg has the right cgroup, and the receiver has SO_PASSCGROUP set, then the receiver gets SCM_CGROUP. If you try to lie using SCM_CGROUP, you get -EPERM. If you set SO_PASSCGROUP, but your peer doesn't sent SCM_CREDS, you get nothing.

This is immune to both attacks. It should be cheaper, too, since there's no overhead for people who don't use it.

I think you seem to be saying that a client's credentials should not be visible to receiver until and unless client himself wants to reveal those. IOW, it kind of looks like an anonymous mode of operation where client connects to a socket but receiver client not want to reveal any of the information about itself to receiver.

Quoted 3 lines

I am not sure how useful that mode really is. If it is really useful, I think one could implement another socket option on client side to deny passing cgroup information to receiver. Say SO_NOPASSCGROUP.

This won't help -- an attacker will simply not set that option, and the program being attacked is certainly not going to set SO_NOPASSCGROUP right before calling write.

Quoted 6 lines

Before we even get there, I will question that what's so secret about cgroup information that one would like to hide it from receiver. We don't hide uid, pid, gid.

I think we should hide uid, gid, and pid too, but that ship has sailed.

The bigger issue isn't hiding so much as accidental assertions of authority. If a program accidentally leaks its uid, that's one thing.
If a program, by accidentally leaking its uid, causes another program
to think that the sender wants some action to be taken on behalf of its uid, then there's a real security problem.

Quoted 5 lines

Secondly, how would client know when to send SCM_CGROUP to receiver. For the use case I mentioned that init wants to log cgroup of every message going into journal. How would client know that every message needs to have SCM_CGROUP. By automatically getting client information when receiver needs it, simplifies the things a lot without any client modificaiton.

I think that the client *should* be modified. What if there's an existing program that runs as a container's root but does not intend to sign off on a message with its cgroup?

In any event, I still think that the journald case has no need for any kernel changes at all. From a very cursory inspection, the journal code expects to find a socket in /run/systemd/journal/socket. It should be enough to stick a different socket into that location in each container. This will work on all kernels and may even work without modifying any code in the container.

Please, just stop.

Quoted 2 lines · David Miller

Please, just stop.

No.

This thread is proposing an ABI. This means that, if the ABI ends up in Linus's kernel, then it has to be supported forever. Now is the time to find and fix any issues with it before they become much harder to fix.

This ABI is especially tricky because programs will use it even if they don't explicitly try to. So just adding the ABI may break existing assumptions that are relevant to security or correctness.

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

Hello,

Quoted 3 lines · Simo Sorce

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

Ugh, please don't play security games with cgroup names. It is one of the identifying properties of a task, like a pid, and will be used in other parts of the kernel to match groups of tasks. If we play security peekaboo with cgroup names, it has to be transitive and puts burdens on all its future uses. Unless there are *REALLY* strong rationales, which can also justify hiding pids, this isn't happening.

Quoted 6 lines · Andy Lutomirski

Quoted 2 lines · David Miller

Please, just stop.

No.

Quoted 4 lines

This thread is proposing an ABI. This means that, if the ABI ends up in Linus's kernel, then it has to be supported forever. Now is the time to find and fix any issues with it before they become much harder to fix.

Ok, but so far I haven't seen a single objection from you that has solid grounds.

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

And if you can come up with such a good reason the SO_NOPASSCGROUP option seem the right solution.

Quoted 3 lines

This ABI is especially tricky because programs will use it even if they don't explicitly try to. So just adding the ABI may break existing assumptions that are relevant to security or correctness.

It's not clear to me what you mean by this, either you explicitly use SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...

Quoted 7 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Quoted 2 lines · David Miller

Please, just stop.

No.

Quoted 7 lines

Quoted 4 lines

This thread is proposing an ABI. This means that, if the ABI ends up in Linus's kernel, then it has to be supported forever. Now is the time to find and fix any issues with it before they become much harder to fix.

Ok, but so far I haven't seen a single objection from you that has solid grounds.

CVE-2013-1959 was caused by a new kernel feature causing a call to write(2) to behave as though the caller was authenticating itself to something else where, in previous kernels, write(2) did not authenticate.

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Quoted 11 lines

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

And if you can come up with such a good reason the SO_NOPASSCGROUP option seem the right solution.

Quoted 3 lines

This ABI is especially tricky because programs will use it even if they don't explicitly try to. So just adding the ABI may break existing assumptions that are relevant to security or correctness.

Quoted 3 lines

It's not clear to me what you mean by this, either you explicitly use SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing the sender to identify or authenticate itself. The sender might not want to identify itself.

Even if you don't buy any secrecy arguments,

the sender might not intend to authenticate. Certainly no existing callers of connect or write intend to authenticate using their cgroup, since current kernels don't have those semantics.

Quoted 21 lines · Andy Lutomirski

Quoted 7 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Quoted 2 lines · David Miller

Please, just stop.

No.

Quoted 7 lines

Quoted 4 lines

This thread is proposing an ABI. This means that, if the ABI ends up in Linus's kernel, then it has to be supported forever. Now is the time to find and fix any issues with it before they become much harder to fix.

Ok, but so far I haven't seen a single objection from you that has solid grounds.

CVE-2013-1959 was caused by a new kernel feature causing a call to write(2) to behave as though the caller was authenticating itself to something else where, in previous kernels, write(2) did not authenticate.

Quoted 3 lines

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Which is easy to foil by using SO_PEERCGROUP and find out who originally opened the socket, which is why that is also available!

Quoted 3 lines

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing the sender to identify or authenticate itself. The sender might not want to identify itself.

You need to explain, why, on a host, when an application connects to another, it is ok to make it anonymous. If you do not want to expose yourself, do not talk to other applications in the first place.

Quoted 4 lines

the sender might not intend to authenticate. Certainly no existing callers of connect or write intend to authenticate using their cgroup, since current kernels don't have those semantics.

This is a passive check, it's the receiver that wants to make decisions about who is connecting, again if you do not want to "disclose" information do not connect in the first place ?

Then please remove SO_PASSCGROUP.

Quoted 1 line · Andy Lutomirski

Then please remove SO_PASSCGROUP.

Can you stop demanding changes while demonstrating you haven't well understood the needs, let alone the consequences ?

Take a day or 2, put your thoughts together and come back with a clear description of your concerns if you still have any, please.

Quoted 6 lines

Quoted 3 lines

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Which is easy to foil by using SO_PEERCGROUP and find out who originally opened the socket, which is why that is also available!

Then please remove SO_PASSCGROUP.

Quoted 5 lines

Quoted 4 lines

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing the sender to identify or authenticate itself. The sender might not want to identify itself.

Quoted 3 lines

You need to explain, why, on a host, when an application connects to another, it is ok to make it anonymous. If you do not want to expose yourself, do not talk to other applications in the first place.

Why is anonymity harmful here? I don't have a great argument off the top of my head for why it's necessary, but neither do I see why it's bad.

And I think a lack of anonymity is asking for trouble (see below).

Quoted 10 lines

Quoted 5 lines

the sender might not intend to authenticate. Certainly no existing callers of connect or write intend to authenticate using their cgroup, since current kernels don't have those semantics.

This is a passive check, it's the receiver that wants to make decisions about who is connecting, again if you do not want to "disclose" information do not connect in the first place ?

Let's say I have a receiver. I'll call it journald, since I think that's one of the eventual use cases.

Let's also say I some random program on my box. It is willing to answer requests on behalf of anyone else with the same uid, and it will happily open a given unix socket and send the requester the file descriptor. Such a program is a bit odd, but it's perfectly safe right now.

Now add a malicious program into the mix. It asks the daemon to open /run/systemd/journal/socket. Then it starts writing to the fd.

Whoops, now the malicious program can impersonate the helper. This happens because SO_PEERCGROUP (and journald's use of SO_PEERCGROUP) caused connect(2) to produce a descriptor that carries a permission that the descriptor did not carry in the past, and because the caller of connect(2) did not need to opt in to the new behavior.

I still haven't seen any explanation for what's wrong with requiring senders to ask the kernel to transmit their cgroup.

On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote:

[..]

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Quoted 4 lines

Quoted 2 lines

Which is easy to foil by using SO_PEERCGROUP and find out who originally opened the socket, which is why that is also available!

Then please remove SO_PASSCGROUP.

SO_PASSCGROUP is important because SO_PEERCGROUP does not work with unix datagram sockets.

Again going back to logging example, if some clients are logging to unix datagram sockets, SO_PASSCGROUP is the only option to figure out cgroup of client.

Quoted 3 lines

I still haven't seen any explanation for what's wrong with requiring senders to ask the kernel to transmit their cgroup.

If nothing else, additional complexity and ovhead. Extra pair of messages need to be exchanged to request and then provide the information.

How would it work in logging example? Every time logger receives a message, is it supposed to send another message to client to send SCM_CGROUP? That does not sound right.

Quoted 7 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote:

[..]

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Which is easy to foil by using SO_PEERCGROUP and find out who originally opened the socket, which is why that is also available!

Then please remove SO_PASSCGROUP.

SO_PASSCGROUP is important because SO_PEERCGROUP does not work with unix datagram sockets.

Right. I forgot about that.

Quoted 1 line

Quoted 3 lines

Again going back to logging example, if some clients are logging to unix datagram sockets, SO_PASSCGROUP is the only option to figure out cgroup of client.

Hmm. I think that, in your patch, the cgroup that is sent is the cgroup of the caller of write/send/sendmsg. What if you changed it to use the same cgroup that SO_PEERCRED would use? Would that still work?

Quoted 8 lines

Quoted 4 lines

I still haven't seen any explanation for what's wrong with requiring senders to ask the kernel to transmit their cgroup.

If nothing else, additional complexity and ovhead. Extra pair of messages need to be exchanged to request and then provide the information.

Quoted 3 lines

How would it work in logging example? Every time logger receives a message, is it supposed to send another message to client to send SCM_CGROUP? That does not sound right.

No -- just have the logger send the cgroup with every message. Yes, it seems silly, but it's probably barely more expensive than with the code in your patch.

Quoted 19 lines · Andy Lutomirski

Quoted 7 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote:

[..]

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Which is easy to foil by using SO_PEERCGROUP and find out who originally opened the socket, which is why that is also available!

Then please remove SO_PASSCGROUP.

SO_PASSCGROUP is important because SO_PEERCGROUP does not work with unix datagram sockets.

Right. I forgot about that.

Quoted 1 line

Quoted 8 lines

Quoted 3 lines

Again going back to logging example, if some clients are logging to unix datagram sockets, SO_PASSCGROUP is the only option to figure out cgroup of client.

Hmm. I think that, in your patch, the cgroup that is sent is the cgroup of the caller of write/send/sendmsg. What if you changed it to use the same cgroup that SO_PEERCRED would use? Would that still work?

No. SO_PEERCRED stores the cgroup information once at the time of connect(). After that it never changes.

What if sender changes the cgroup. That information will not be captured. Also what if multiple client use the same socket fd to writer to logger? In that case too storing cgroup info in socket will not help.

Quoted 7 lines

Quoted 3 lines

How would it work in logging example? Every time logger receives a message, is it supposed to send another message to client to send SCM_CGROUP? That does not sound right.

No -- just have the logger send the cgroup with every message. Yes, it seems silly, but it's probably barely more expensive than with the code in your patch.

So receiver gets the cgroup messages even if it might not want to. There is no way to say "Hey don't send me SCM_CGROUP's messages".

Now all loggers need to be modifed to always send SCM_CGROUP messages. And all other more complicated cases might need a different consideration and clients and servers will need to be modified accordingly.

I think it is much simpler to allow passing of cgroup information and once we figure out some concrete cases where passing of that info is not desirabe, implement SO_NOPASSCGROUP and modify those *selected few corner cases* to set this flag on sockets.

Quoted 7 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Quoted 2 lines · David Miller

Please, just stop.

No.

Quoted 7 lines

Quoted 4 lines

This thread is proposing an ABI. This means that, if the ABI ends up in Linus's kernel, then it has to be supported forever. Now is the time to find and fix any issues with it before they become much harder to fix.

Ok, but so far I haven't seen a single objection from you that has solid grounds.

CVE-2013-1959 was caused by a new kernel feature causing a call to write(2) to behave as though the caller was authenticating itself to something else where, in previous kernels, write(2) did not authenticate.

Admittedly cgroups aren't currently as important as uid, but if this changes, then SO_PASSCGROUP, as currently written, will have *exactly* the same problem.

Quoted 9 lines

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

And if you can come up with such a good reason the SO_NOPASSCGROUP option seem the right solution.

Quoted 7 lines

Quoted 3 lines

This ABI is especially tricky because programs will use it even if they don't explicitly try to. So just adding the ABI may break existing assumptions that are relevant to security or correctness.

It's not clear to me what you mean by this, either you explicitly use SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing the sender to identify or authenticate itself. The sender might not want to identify itself. Even if you don't buy any secrecy arguments, the sender might not intend to authenticate. Certainly no existing callers of connect or write intend to authenticate using their cgroup, since current kernels don't have those semantics.

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 17 lines

Quoted 9 lines

The only one that *may* be reasonable is the "secret" cgroup name one, however nobody seem to come up with a reason why it is legitimate to allow to keep cgroup names secret.

And if you can come up with such a good reason the SO_NOPASSCGROUP option seem the right solution.

Quoted 7 lines

Quoted 3 lines

This ABI is especially tricky because programs will use it even if they don't explicitly try to. So just adding the ABI may break existing assumptions that are relevant to security or correctness.

It's not clear to me what you mean by this, either you explicitly use SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...

Quoted 6 lines

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing the sender to identify or authenticate itself. The sender might not want to identify itself. Even if you don't buy any secrecy arguments, the sender might not intend to authenticate. Certainly no existing callers of connect or write intend to authenticate using their cgroup, since current kernels don't have those semantics.

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.

I agree that before somebody uses cgroup information for authentication purposes, may be there needs to be a bigger debate whether this info can be used safely for authentication purposes or not and in what circumstances it is safe to use for authentication.

But that does not mean that API to pass the cgroup information around is wrong.

Quoted 4 lines

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.

Quoted 6 lines

I agree that before somebody uses cgroup information for authentication purposes, may be there needs to be a bigger debate whether this info can be used safely for authentication purposes or not and in what circumstances it is safe to use for authentication.

I thought that the original intended user of these patches was SSSD. I have no idea what SSSD wanted them for, but I think it may better.

Quoted 5 lines

But that does not mean that API to pass the cgroup information around is wrong.

It may not be wrong, but it might be extremely difficult or impossible to use it safely. I think that's something to avoid.

On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:

[..]

Quoted 8 lines

Quoted 4 lines

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.

Quoted 12 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:

[..]

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

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.

Is the reason that you don't want to modify the senders because you want users of syslog(3) to get the new behavior? If so, I think it would be nice to update glibc to fix that, but maybe the kernel should cooperate, and maybe SO_PEERCGROUP is a decent way to handle this.

I still think that SO_PASSCGROUP, as currently designed, is problematic.

Quoted 19 lines · Andy Lutomirski

Quoted 12 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:

[..]

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 6 lines

Is the reason that you don't want to modify the senders because you want users of syslog(3) to get the new behavior? If so, I think it would be nice to update glibc to fix that, but maybe the kernel should cooperate, and maybe SO_PEERCGROUP is a decent way to handle this.

Modifying every user of unix sockets to start passing cgroup information will make sense only if it was deemed that passing cgroup information is risky inherently and should be done only in selected cases.

I think so far our understanding is that we can't find anything inherently wrong with passing cgroup information, though there might be some corner cases we can run into and which are not obivious right now.

Quoted 29 lines · Vivek Goyal

Quoted 19 lines · Andy Lutomirski

Quoted 12 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:

[..]

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 12 lines

Quoted 7 lines

Is the reason that you don't want to modify the senders because you want users of syslog(3) to get the new behavior? If so, I think it would be nice to update glibc to fix that, but maybe the kernel should cooperate, and maybe SO_PEERCGROUP is a decent way to handle this.

Modifying every user of unix sockets to start passing cgroup information will make sense only if it was deemed that passing cgroup information is risky inherently and should be done only in selected cases.

Quoted 4 lines

I think so far our understanding is that we can't find anything inherently wrong with passing cgroup information, though there might be some corner cases we can run into and which are not obivious right now.

I think I've explained why causing write(2) to start transmitting the caller's cgroup is problematic. Your SO_PASSCGROUP patch does that. Your SO_PEERCGROUP patch does not.

I'm still nervous about SO_PEERCGROUP and about a variant of SO_PASSCGROUP that used the cgroup as of the time of connect(2), but I'm much less convinced that there's an actual problem. My nervousness here is more that I don't like APIs that aren't clearly safe.

Quoted 36 lines · Andy Lutomirski

Quoted 29 lines · Vivek Goyal

Quoted 19 lines · Andy Lutomirski

Quoted 12 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:

[..]

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

Quoted 10 lines · Andy Lutomirski

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 4 lines

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

If you can't prove that there is something fundamentally wrong with passing cgroup info to receiver, there is no reason to block these patches either.

We can't fix the problems which we can't see. You are saying that I don't know what kind of problem can happen due to cgroup passing. Still that does not mean none of the problems exist. So let us not pass cgroup info by default and ask client to opt in.

I don't think this is a very convincing argument.

To me, if we can't see anything fundamentally wrong with passing cgroup info, we should take these patches in. And once we figure out that there is are problematic use cases, then implement SO_NOPASSCGROUP and SO_NOPEERCRED and allow problematic clients to opt out.

Thanks
Vivek

Quoted 26 lines · Vivek Goyal

Quoted 10 lines · Andy Lutomirski

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 4 lines

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

If you can't prove that there is something fundamentally wrong with passing cgroup info to receiver, there is no reason to block these patches either.

We can't fix the problems which we can't see. You are saying that I don't know what kind of problem can happen due to cgroup passing. Still that does not mean none of the problems exist. So let us not pass cgroup info by default and ask client to opt in.

I don't think this is a very convincing argument.

Quoted 7 lines

To me, if we can't see anything fundamentally wrong with passing cgroup info, we should take these patches in. And once we figure out that there is are problematic use cases, then implement SO_NOPASSCGROUP and SO_NOPEERCRED and allow problematic clients to opt out.

Thanks
Vivek

The two use cases for this patch are:

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

2 Potentially reveal different information to the caller based on the cgroup information.

Imagine you want to set up an apache web server that is going to use sssd for authentication data. You might want to reveal a limited set of users to the apache service process based on the fact that it is running in the apache.service.slice. If the apache service does the equivalent of getent passwd I want to give it different information then say sshd did the same calls.

Quoted 27 lines · Daniel J Walsh

Quoted 26 lines · Vivek Goyal

Quoted 10 lines · Andy Lutomirski

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 4 lines

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

If you can't prove that there is something fundamentally wrong with passing cgroup info to receiver, there is no reason to block these patches either.

We can't fix the problems which we can't see. You are saying that I don't know what kind of problem can happen due to cgroup passing. Still that does not mean none of the problems exist. So let us not pass cgroup info by default and ask client to opt in.

I don't think this is a very convincing argument.

Quoted 8 lines

Quoted 7 lines

To me, if we can't see anything fundamentally wrong with passing cgroup info, we should take these patches in. And once we figure out that there is are problematic use cases, then implement SO_NOPASSCGROUP and SO_NOPEERCRED and allow problematic clients to opt out.

Thanks
Vivek

The two use cases for this patch are:

Let me add some caveats to explain what is used, as the 2 cases map to the 2 different new options.

Quoted 2 lines

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

In here the logging system wants to know *who* logged, if the cgroups of the process actually doing the logging changes, that's what the logging system wants to know.
If somehow a setuid binary can change the cgroups, then the logging system *wants* to know that these logs are coming from there, because they sure are not coming from the original bounded process anymore.

This use case wants to use SO_PASSCGROUP as it wants to know who the current writer is, not who opened the file descriptor.

Quoted 50 lines · Simo Sorce

Quoted 27 lines · Daniel J Walsh

Quoted 26 lines · Vivek Goyal

Quoted 10 lines · Andy Lutomirski

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 4 lines

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

If you can't prove that there is something fundamentally wrong with passing cgroup info to receiver, there is no reason to block these patches either.

We can't fix the problems which we can't see. You are saying that I don't know what kind of problem can happen due to cgroup passing. Still that does not mean none of the problems exist. So let us not pass cgroup info by default and ask client to opt in.

I don't think this is a very convincing argument.

Quoted 8 lines

Quoted 7 lines

To me, if we can't see anything fundamentally wrong with passing cgroup info, we should take these patches in. And once we figure out that there is are problematic use cases, then implement SO_NOPASSCGROUP and SO_NOPEERCRED and allow problematic clients to opt out.

Thanks
Vivek

The two use cases for this patch are:

Let me add some caveats to explain what is used, as the 2 cases map to the 2 different new options.

Quoted 2 lines

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

In here the logging system wants to know *who* logged, if the cgroups of the process actually doing the logging changes, that's what the logging system wants to know.
If somehow a setuid binary can change the cgroups, then the logging system *wants* to know that these logs are coming from there, because they sure are not coming from the original bounded process anymore.

Quoted 2 lines

This use case wants to use SO_PASSCGROUP as it wants to know who the current writer is, not who opened the file descriptor.

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.

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.

Yes, I don't see how this is exploitable on my machine, but it's a mistake for the same reason that the netlink crap in CVE-2014-0181 is a mistake.

FWIW, there are a handful of people who think about security and occasionally answer things on lkml. Some of them will tell you once that a patch is a problem, and then they'll watch you ignore it, and then they'll pwn you later on. This has happened to me. I'm not one of those people, though, but it's generally good policy to pay attention when people tell you that your proposed API *cannot* be used safely.

Quoted 5 lines · Andy Lutomirski

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.

Quoted 3 lines

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.

I repeat, it is *not* access control.

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 2 lines

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.

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 38 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

Quoted 5 lines

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Quoted 45 lines · Andy Lutomirski

Quoted 43 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 2 lines

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time and if receiver uses that info for access control, it can be problematic.

Quoted 46 lines · Vivek Goyal

Quoted 45 lines · Andy Lutomirski

Quoted 43 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 6 lines

Quoted 2 lines

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time and if receiver uses that info for access control, it can be problematic.

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

You do realize that we have been speaking in hypothetical for a while now ?

Even without doing the SO_PEERCRED, you are not going to fool the log, as it gathers a ton of other info about the process, and cgroup is just one of the infos used to classify the log.

There are also credentials, pid, and a lot of other things. Even if a setuid binary could be tricked to send a message with an "impostor" cgroup don't you think you'd see other things out of place ? (wrong uid, wrong pid, etc...).

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

Quoted 31 lines · Simo Sorce

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Quoted 4 lines

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

Quoted 32 lines · Vivek Goyal

Quoted 31 lines · Simo Sorce

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Quoted 7 lines

Quoted 4 lines

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

I don't know how it will even be used for systemd logging case. systemd provides various ways to connect stdout of services. So say a service's stdout is connected to a connected datagram socket and all printf() messages to stdout are being logged by receiver in journal. Now how would sender know that it is supposed to send SCM_CGROUP? One needs to modify printf() now?

Thanks
Vivek

Quoted 41 lines · Vivek Goyal

Quoted 32 lines · Vivek Goyal

Quoted 31 lines · Simo Sorce

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Quoted 7 lines

Quoted 4 lines

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

Quoted 6 lines

I don't know how it will even be used for systemd logging case. systemd provides various ways to connect stdout of services. So say a service's stdout is connected to a connected datagram socket and all printf() messages to stdout are being logged by receiver in journal. Now how would sender know that it is supposed to send SCM_CGROUP? One needs to modify printf() now?

Does connecting stdout to a datagram socket really work well? The systemd function connect_logger_as looks like it's using stream sockets, one per service, connected to /run/systemd/journal/stdout. There's some rather strange logic in journald to authenticate the thing that connects (using SO_PEERCRED!), but I don't see why this code would even want to use SCM_CGROUP.

IOW, write(2) issues notwithstanding, I'm still wondering what the use case for this whole thing is.

Quoted 56 lines · Andy Lutomirski

Quoted 41 lines · Vivek Goyal

Quoted 32 lines · Vivek Goyal

Quoted 31 lines · Simo Sorce

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Quoted 7 lines

Quoted 4 lines

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

Quoted 6 lines

I don't know how it will even be used for systemd logging case. systemd provides various ways to connect stdout of services. So say a service's stdout is connected to a connected datagram socket and all printf() messages to stdout are being logged by receiver in journal. Now how would sender know that it is supposed to send SCM_CGROUP? One needs to modify printf() now?

Does connecting stdout to a datagram socket really work well? The systemd function connect_logger_as looks like it's using stream sockets, one per service, connected to /run/systemd/journal/stdout. There's some rather strange logic in journald to authenticate the thing that connects (using SO_PEERCRED!), but I don't see why this code would even want to use SCM_CGROUP.

Quoted 2 lines

IOW, write(2) issues notwithstanding, I'm still wondering what the use case for this whole thing is.

I "think" the use case is to aggregate all the logs that belong to a specific service by using a cgroup name, then, as long as children do not close stdout/stderr anything they emit would be captured and properly filed with the rest of the logs from the other process of the same control group, which has been made to mean "the service".

I also "think" using datagram sockets may be an attempt to reduce the number of sockets that need to be kept open and polled on the receiving side.

Quoted 31 lines · Simo Sorce

Quoted 9 lines · Andy Lutomirski

Quoted 8 lines · Simo Sorce

Quoted 6 lines · Andy Lutomirski

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 7 lines

Quoted 4 lines

But there is no attack vector that passes by tricking setuid binaries to write to pre-opened file descriptors on sendmsg(), and for the other cases (connected socket) journald can always cross check with SO_PEERCGROUP, so why do we care again ?

Because the proposed code does not do what I described, at least as far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a datagram socket then you *can* write() (thanks to Vivek for checking this).

So you can trick something to write() to it but you can't do SO_PEERCGROUP on the other side, because it is not really a connected socket, the connection is only faked on the sender side by constructing sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to explicitly pass cgroup data on unix datagram sockets may be an acceptable request IMO.

Quoted 4 lines

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

At this point I think journald people need to give a little bit more details on how they plan to use SO_PASSCGROUP.

For my use cases I care only about streams and SO_PEERCGROUP that does not have any of the (perceived) issues of SO_PASSCGROUP.

On Thu, Apr 17, 2014 at 03:10:17PM -0400, Simo Sorce wrote:

[..]

Quoted 5 lines

At this point I think journald people need to give a little bit more details on how they plan to use SO_PASSCGROUP.

For my use cases I care only about streams and SO_PEERCGROUP that does not have any of the (perceived) issues of SO_PASSCGROUP.

Ok, so we agree that SO_PEERCGROUP is not a problem. And it solves the problem for some of the use cases.

And there is lot of contention on the SO_PASSCGROUP option.

So how about taking one step at a time. Get SO_PEERCGROUP in first and then get into more details on how SO_PASSCGROUP will exactly be used and then decide what to do.

Quoted 14 lines · Vivek Goyal

On Thu, Apr 17, 2014 at 03:10:17PM -0400, Simo Sorce wrote:

[..]

Quoted 5 lines

At this point I think journald people need to give a little bit more details on how they plan to use SO_PASSCGROUP.

For my use cases I care only about streams and SO_PEERCGROUP that does not have any of the (perceived) issues of SO_PASSCGROUP.

Ok, so we agree that SO_PEERCGROUP is not a problem. And it solves the problem for some of the use cases.

And there is lot of contention on the SO_PASSCGROUP option.

Quoted 3 lines

So how about taking one step at a time. Get SO_PEERCGROUP in first and then get into more details on how SO_PASSCGROUP will exactly be used and then decide what to do.

My only objection to SO_PEERCGROUP is that I don't believe that a legitimate use case exists. I think the feature itself is safe to add.

So what happened to logger use case where logger accepts stream connections and logs the cgroup of client too.

W.r.t systemd, looks like journald is accepting connections at /run/systemd/journal/stdout. (stdout_stream_new() and server_open_stdout_socket()).

To summarize from my reading of how this crap words:

When a unit is created, systemd opens a stream socket pointing at /run/systemd/journal/stdout. It tells journald the unit, along with lots of other useful information. journald records this association between the socket and the unit. Systemd could tell journald the cgroup here, too, if it wanted it.

On Mon, Apr 21, 2014 at 08:47:51AM -0700, Andy Lutomirski wrote:

[..]

Quoted 7 lines

To summarize from my reading of how this crap words:

When a unit is created, systemd opens a stream socket pointing at /run/systemd/journal/stdout. It tells journald the unit, along with lots of other useful information. journald records this association between the socket and the unit. Systemd could tell journald the cgroup here, too, if it wanted it.

Ok, that's a fair point. I looked at connect_logger_as() and I see that systemd does connect() on behalf of service being launched and sets up fd and passes bunch of information to journald. So cgroup could be one of the information and that would act like SO_PEERCGROUP in this specific case. Not sure why it is not done though. I will let systemd folks comment on that. I don't have enough background here.

But this works in this specific case where there is a mechanism to pass meta information to receiver. What about SSSD use case where they want to know the cgroup of client and possibly provide differentiated service based on client.

Also Dan Walsh mentioned that what if a process directly wants to open journal socket and log something to journal.

Quoted 18 lines · Vivek Goyal

On Mon, Apr 21, 2014 at 08:47:51AM -0700, Andy Lutomirski wrote:

[..]

Quoted 7 lines

To summarize from my reading of how this crap words:

When a unit is created, systemd opens a stream socket pointing at /run/systemd/journal/stdout. It tells journald the unit, along with lots of other useful information. journald records this association between the socket and the unit. Systemd could tell journald the cgroup here, too, if it wanted it.

Ok, that's a fair point. I looked at connect_logger_as() and I see that systemd does connect() on behalf of service being launched and sets up fd and passes bunch of information to journald. So cgroup could be one of the information and that would act like SO_PEERCGROUP in this specific case. Not sure why it is not done though. I will let systemd folks comment on that. I don't have enough background here.

Quoted 4 lines

But this works in this specific case where there is a mechanism to pass meta information to receiver. What about SSSD use case where they want to know the cgroup of client and possibly provide differentiated service based on client.

Separate sockets sounds like it will work just fine, if not better, here, to me.

Quoted 4 lines · Simo Sorce

Perhaps this could be done with a sendmsg() header flag or simplified ancillary data even, rather than forcing the sender process to retrieve and construct the whole information which is already available in kernel.

So what would be the protocol here? When should somebody send an SCM_CGROUP message using sendmsg()?

Quoted 46 lines · Vivek Goyal

Quoted 45 lines · Andy Lutomirski

Quoted 43 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 6 lines

Quoted 2 lines

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time and if receiver uses that info for access control, it can be problematic.

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 54 lines · Andy Lutomirski

Quoted 46 lines · Vivek Goyal

Quoted 45 lines · Andy Lutomirski

Quoted 43 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 6 lines

Quoted 2 lines

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time and if receiver uses that info for access control, it can be problematic.

Quoted 5 lines

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

So you are telling me that you want to change all code that writes to stderr to be changed to use sendmsg() instead of write() in order to get that information ?

If you are using datagram sockets then the sender explicitly has to use sendmsg() already and if a setuid binary can be convinced to send arbitrary data to an arbitrary datagram sokcet you have bigger problems in that binary, and said binary will send you whatever cgroup it is in.

Quoted 61 lines · Simo Sorce

Quoted 54 lines · Andy Lutomirski

Quoted 46 lines · Vivek Goyal

Quoted 45 lines · Andy Lutomirski

Quoted 43 lines · Simo Sorce

Quoted 25 lines · Andy Lutomirski

Quoted 10 lines · Simo Sorce

Quoted 5 lines · Andy Lutomirski

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

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.

Well journald can *also* get SO_PEERCGROUP and log anomalies if the 2 differ. That is if the log happens on a connected socket.

If the log happens on a unix datagram* then SO_PEERCGROUP is not available because there is no connect(), however write() cannot be used either, only sendmsg() AFAIK, so the "setuid" binary attack does not apply.

Quoted 6 lines

Quoted 2 lines

Or you could only send SCM_CGROUP when the writer asks sendmsg to send it, in which case this whole problem goes away.

Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time and if receiver uses that info for access control, it can be problematic.

Quoted 5 lines

Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2) who supply SCM_CGROUP are explicitly indicating that they want their cgroup associated with that message. Callers of write(2) and send(2) are simply indicating that they have some bytes that they want to shove into whatever's at the other end of the fd.

Quoted 3 lines

So you are telling me that you want to change all code that writes to stderr to be changed to use sendmsg() instead of write() in order to get that information ?

No. I'm telling you that I want whoever writes the logging code to change *the logging code* to use sendmsg.

Quoted 4 lines

If you are using datagram sockets then the sender explicitly has to use sendmsg() already and if a setuid binary can be convinced to send arbitrary data to an arbitrary datagram sokcet you have bigger problems in that binary, and said binary will send you whatever cgroup it is in.

Really?

Quoted 50 lines · Simo Sorce

Quoted 27 lines · Daniel J Walsh

Quoted 26 lines · Vivek Goyal

Quoted 10 lines · Andy Lutomirski

Quoted 9 lines · Vivek Goyal

On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
I am not sure how same issue with happen with cgroups. In the case of socket example, you are forcing a setuid program to write to standard output and that setuid program will run in same cgroup as caller and will have same cgroup as caller. So even if somebody was using cgroup information for authentication, atleast in this particular case it will not be a problem. Both unpriviliged and priviliged programs has same cgroups.

Quoted 4 lines

I'm not sure that there's an actual attackable program. But I also see no reason to be convinced that there isn't one, and the problem can easily be avoided by requiring programs to explicitly ask to send their cgroup.

If you can't prove that there is something fundamentally wrong with passing cgroup info to receiver, there is no reason to block these patches either.

We can't fix the problems which we can't see. You are saying that I don't know what kind of problem can happen due to cgroup passing. Still that does not mean none of the problems exist. So let us not pass cgroup info by default and ask client to opt in.

I don't think this is a very convincing argument.

Quoted 8 lines

Quoted 7 lines

To me, if we can't see anything fundamentally wrong with passing cgroup info, we should take these patches in. And once we figure out that there is are problematic use cases, then implement SO_NOPASSCGROUP and SO_NOPEERCRED and allow problematic clients to opt out.

Thanks
Vivek

The two use cases for this patch are:

Let me add some caveats to explain what is used, as the 2 cases map to the 2 different new options.

Quoted 2 lines

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

In here the logging system wants to know *who* logged, if the cgroups of the process actually doing the logging changes, that's what the logging system wants to know.
If somehow a setuid binary can change the cgroups, then the logging system *wants* to know that these logs are coming from there, because they sure are not coming from the original bounded process anymore.

Quoted 2 lines

This use case wants to use SO_PASSCGROUP as it wants to know who the current writer is, not who opened the file descriptor.

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.

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. Yes, I don't see how this is exploitable on my machine, but it's a mistake for the same reason that the netlink crap in CVE-2014-0181 is a mistake.

On 04/16/2014 11:59 AM, Vivek Goyal wrote:
The two use cases for this patch are:

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

2 Potentially reveal different information to the caller based on the cgroup information.

Imagine you want to set up an apache web server that is going to use sssd for authentication data. You might want to reveal a limited set of users to the apache service process based on the fact that it is running in the apache.service.slice. If the apache service does the equivalent of getent passwd I want to give it different information then say sshd did the same calls.

The two use cases for this patch are:

1 Logging, to make sure the cgroup information gets correctly attributed to the caller.

2 Potentially reveal different information to the caller based on the cgroup information.

Imagine you want to set up an apache web server that is going to use sssd for authentication data. You might want to reveal a limited set of users to the apache service process based on the fact that it is running in the apache.service.slice. If the apache service does the equivalent of getent passwd I want to give it different information then say sshd did the same calls.

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

[..]

Quoted 3 lines

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

If this is a problem then I think kernel requires fixing. Because kernel will apply all resource management policies based on the cgroup at write(2) time and not based on open() time.

From: Vivek Goyal <[email protected]>
Date: Wed, 23 Apr 2014 12:45:37 -0400

Quoted 10 lines · Andy Lutomirski

[..]

Quoted 3 lines

Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated.

If this is a problem then I think kernel requires fixing. Because kernel will apply all resource management policies based on the cgroup at write(2) time and not based on open() time.

Anyways, this is not even worth discussing.

We already agreed that the cgroup passed at write time with SO_PASSGROUP enabled should be the socket creation time cgroup.

Just like SO_PASSCRED does.

The identity given is thus the one at open() time.

By open() time you mean at socket() time or at connect() time?

You also mentioned that you want SO_PEERCGROUP and SO_PASSCGROUP as pairs like SO_PEERCRED and SO_PASSCRED. But to me, SO_PEERCRED and SO_PASSCRED are not *exact* pairs and are little different in their semantics. SO_PEERCRED gives us client creds at connect() time while SO_PASSCRED client's real creds at sendmsg() time. SO_PASSCRED does not store client's credential's at connect() time for datagram sockets.

From: Vivek Goyal <[email protected]>
Date: Thu, 24 Apr 2014 16:34:27 -0400

Quoted 1 line

By open() time you mean at socket() time or at connect() time?

I mean at all of the places at which init_peercred() occurs.

Quoted 8 lines

You also mentioned that you want SO_PEERCGROUP and SO_PASSCGROUP as pairs like SO_PEERCRED and SO_PASSCRED. But to me, SO_PEERCRED and SO_PASSCRED are not *exact* pairs and are little different in their semantics. SO_PEERCRED gives us client creds at connect() time while SO_PASSCRED client's real creds at sendmsg() time. SO_PASSCRED does not store client's credential's at connect() time for datagram sockets.

Then you haven't been following the discussion.

The client's credentials at sendmsg()/write() time are "DO NOT CARE".

You cannot even guarentee the semantics in the logging example if you ask for these "client identity at sendmsg() time" semantics.

What if the event occured when the client was in cgroup1, and the log message goes out after it has been moved into cgroup2?

That is just proof that this whole idea is fundamentally flawed.

Does it really matter.

From: Vivek Goyal <[email protected]>
Date: Thu, 24 Apr 2014 17:04:29 -0400

Quoted 1 line

Does it really matter.

Good question, if it doesn't matter, you might as well log garbage.

There are a lot of logical holes in this discussion.

Real UIDs are always reported at sendmsg() time, not effective ones (the UID "at sendmsg() time").

Therefore if we were to add CGROUP passing at sendmsg() time it should report the "real cgroup", the one the task has at the time the file descriptor / socket was "created".

This is another version of patchset to add support passing cgroup information of client over unix socket API.

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie. the cgroup at socket open() time.

Quoted 10 lines

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Quoted 3 lines

Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie. the cgroup at socket open() time.

I suspect that making this change will render it useless, unfortunately. I really want to understand the use case.

From: Andy Lutomirski <[email protected]>
Date: Tue, 22 Apr 2014 13:08:59 -0700

Quoted 11 lines · David Miller

Quoted 10 lines

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Quoted 6 lines

Quoted 3 lines

Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie. the cgroup at socket open() time.

I suspect that making this change will render it useless, unfortunately. I really want to understand the use case.

There was no use case, it is simply the fact that when I discussed this feature with Vivek and Simo I told them that it should be implemented the same as the existing credential facilities.

For datagram situations there is no "peer" to consider in between sendmsg() calls, as the binding is only active during the sendmsg() call.

That's why SO_PASSCRED exists in the first place.

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Quoted 25 lines

From: Andy Lutomirski <[email protected]>
Date: Tue, 22 Apr 2014 13:08:59 -0700

Quoted 11 lines · David Miller

Quoted 10 lines

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Quoted 6 lines

Quoted 3 lines

Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie. the cgroup at socket open() time.

I suspect that making this change will render it useless, unfortunately. I really want to understand the use case.

There was no use case, it is simply the fact that when I discussed this feature with Vivek and Simo I told them that it should be implemented the same as the existing credential facilities.

Quoted 8 lines

For datagram situations there is no "peer" to consider in between sendmsg() calls, as the binding is only active during the sendmsg() call.

That's why SO_PASSCRED exists in the first place.

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Right.

I'd still like to know what userspace applications want this feature. The canonical example seems to be journald, but journald doesn't use unix datagram sockets AFAICS, nor is the process that opened the socket interesting (that process is always systemd).

From: Andy Lutomirski <[email protected]>
Date: Tue, 22 Apr 2014 13:31:13 -0700

Quoted 35 lines · David Miller

Quoted 25 lines

From: Andy Lutomirski <[email protected]>
Date: Tue, 22 Apr 2014 13:08:59 -0700

Quoted 11 lines · David Miller

Quoted 10 lines

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Quoted 6 lines

Quoted 3 lines

Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie. the cgroup at socket open() time.

I suspect that making this change will render it useless, unfortunately. I really want to understand the use case.

There was no use case, it is simply the fact that when I discussed this feature with Vivek and Simo I told them that it should be implemented the same as the existing credential facilities.

Quoted 8 lines

For datagram situations there is no "peer" to consider in between sendmsg() calls, as the binding is only active during the sendmsg() call.

That's why SO_PASSCRED exists in the first place.

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Quoted 6 lines

Right.

I'd still like to know what userspace applications want this feature. The canonical example seems to be journald, but journald doesn't use unix datagram sockets AFAICS, nor is the process that opened the socket interesting (that process is always systemd).

It's about rounding out the interface properly, now, rather than having to have a specific use case.

I really don't consider a specific use case as a requirement in this case.

Quoted 2 lines

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Right.

I'd still like to know what userspace applications want this feature. The canonical example seems to be journald, but journald doesn't use unix datagram sockets AFAICS,

On Tue, Apr 22, 2014 at 01:31:13PM -0700, Andy Lutomirski wrote:
[..]

Quoted 4 lines

Quoted 2 lines

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Right.

Quoted 3 lines

I'd still like to know what userspace applications want this feature. The canonical example seems to be journald, but journald doesn't use unix datagram sockets AFAICS,

Dan Walsh mentiond that systemd also monitors /dev/log (datagram socket) and logs everything in journal. There this information should be useful.

Thanks
Vivek

Quoted 6 lines · Vivek Goyal

On Tue, Apr 22, 2014 at 01:31:13PM -0700, Andy Lutomirski wrote:
[..]

Quoted 4 lines

Quoted 2 lines

Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets to find out the peer's open() time cgroup.

Right.

Quoted 8 lines

Quoted 3 lines

I'd still like to know what userspace applications want this feature. The canonical example seems to be journald, but journald doesn't use unix datagram sockets AFAICS,

Dan Walsh mentiond that systemd also monitors /dev/log (datagram socket) and logs everything in journal. There this information should be useful.

Thanks
Vivek

I am fine with collecting only the information available at "open". I can potentially see other Userspace Resource Constraints being built based on the Cgroup the process is in. For example openshift wants to limit the amount of email a process can send to only a few per second, which might be able to be controlled by a relay listening on a particular socket. Then it could change the rules based on the Cgroup/Unit file the calling process was in.

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Quoted 9 lines · David Miller

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Does this concern of passing of real uid apply to cgroups also. Even if somebody tricks suid program to write to fd setup by under priviliged program how would that pgram force setuid program to change cgroup.

To me passing cgroup information looks more like "pid" information where we pass the actual pid of setuid program and not the pid of parent who setup fd.

How would one trick setuid program change cgroup? If not, then this class of attack does not seem to apply to SO_PASSCGROUP.

So I think real discussion here should be how "cgroup" information should be used and not necessarily whether we should be passing cgroup information of sender. This information is already available. One can do SO_PASSCRED, get pid, get /proc/pid/cgroup and use cgroup in whatever way they want.

Quoted 9 lines · David Miller

From: Vivek Goyal <[email protected]>
Date: Tue, 15 Apr 2014 17:15:44 -0400

Quoted 2 lines

This is another version of patchset to add support passing cgroup information of client over unix socket API.

I'm marking this patch series as "changes requested" in patchwork because if we still end up adding this feature SO_PASSCGROUP needs to be changed to behave like SO_PASSCRED.

Does this concern of passing of real uid apply to cgroups also. Even if somebody tricks suid program to write to fd setup by under priviliged program how would that pgram force setuid program to change cgroup.

To me passing cgroup information looks more like "pid" information where we pass the actual pid of setuid program and not the pid of parent who setup fd.