On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > Hello Mirek, > > This is the most constructive reply I've seen in this thread. > > On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote: > > > But doesn't satisfy our security requirements. If the kernel dbus project > > > had been successful, then Linux would have had a rock solid basis to > > > allow impersonation which would satisfy the security requirements and > > > allow the desktop actually go through a common criteria certification if > > > any one ever wanted to do that. But as it stands, anything created by > > > IPC is missing the necessary security context. > > > > I mean, yes. I read that as not a reason to stick with set-uid, but as a > > reason to make that a priority, and drive the investment and the cultural > > change; otherwise Linux security is just going to keep falling behind. OTOH > > with the consolehelper history and a lot of similar examples, I don’t know > > how to do any of that (make it a priority, drive the investment, drive the > > cultural change). > > Linux needs a first class impersonation mechanism. This would be where the > kernel bestows upon a process, certain attributes from another process. Both > sides should agree so that no toke kidnapping is possible or forcing > credentials on an unsuspecting process. With something like this, we can > start to solve the security problems caused by IPC instantiation. I was > really hoping kernel dbus was successful way back when. > Windows has a first class impersonation mechanism, and it's really quite complicated and far from rock solid. I don't think Linux should go that direction. But I'm a bit baffled by the assertion that anything created by IPC is missing the necessary security context. The entire world of distributed systems is missing this security context. When I issue REST request or a gRPC request or really any network request at all, I have precisely whatever context I specifically authenticate with for that call. And, other than the fact that most systems use rather weak authentication systems (mostly bearer tokens), this is *good* -- it means that the credential being presented is, by construction, intentional on the part of the presenter. It also means that incorrect inferences aren't drawn. For example, in a world where an entire security context comes along with a request, if process A asks database server B to write a row *over a network*, and B asks the filesystem (C) to do the write, we don't magically attribute more of B's context than we should to the write. I would love to see a nice security model for IPC in the Linux kernel, but I haven't seen a credible proposal. This problem is *hard*. As for setuid, I'm strongly of the opinion that setuid was and remains a mistake. Executing a process should never add privileges. Replacing sudo, etc well probably requires a mechanism by which a process can allow a daemon to either create children of that process or replace that process (in the exec sense). The SELinux label to apply to the newly created process should be the daemon's decision -- it's far from obvious that a sudo'd program should inherit sudo's caller's label. --Andy > > > > And access decisions do not go through the audit system. > > > > For polkit, that would be… a 20-line patch? > > Probably a little more. The auditing would need to be selective and by admin > control. Meaning, the admin may decide that they want auditing of one > application's permission grants and not the other. > > > Sure, the invoking user’s configuration can be trusted only to the extent a > > D-Bus server provides it correctly to Polkit, making the D-Bus servers a > > part of the trusted codebase. Still, that would be pretty valuable at least > > until the first successful exploit. > > I was hoping with kernel dbus, polkit would have examined the connections > itself and asked the kernel for veracity of the request. I really wished that > was given another try and everyone agreed on why it was necessary so that it > could be articulated well to the people that have to say yes/no to the patch. > > -Steve > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
