This whole mess just makes me think we should try harder to kick suid/fcaps out of general purpose Linux distributions. The whole concept is fundamentally backwards, and one of the major weaknesses of traditional UNIX I am sure. The idea behind suid/fcaps of first granting the privileges, inheriting some major, uncontrolled part of the execution environment/resource context/security context and then expecting the binary to securely gate its misuse is just a major mistake: https://www.openwall.com/lists/oss-security/2023/10/03/2
I'd welcome a distribution that'd try hard to address this, and basically run the whole OS with NNP set. Of course, this is not an easy task, people expect their su/sudo to just work, but I am sure these are all addressable, by switching to IPC based privilege elevation for such things.
@mariusor unlikely. And D-Bus has its weaknesses, but security-wise it's a lot more sound than suid/fcaps mess. It has interactive auth via Polkit even. I mean, I'd do it differently sure in my ideal world that only exists in my head, but it's a fundamental improvement over fucking suid/fcaps, hence all power to D-Bus.
@Foxboron as a first step towards that goal distros should start binding ssh to some well--known fixed AF_UNIX socket, so that people can just use it on the local host, and between local containers.
@funkylab sorry, but IPC based elevation, where privileged processes are clearly separated and reasonably isolated is always better than a mess where a process gains privileges and continues running.
I am sure privileges should never be gained, they should only be dropped.
@jamesh@dalias@mariusor I think the idea to imply a certain language was misguided. I – with the knowledge I have today – would have tried to use a simpler, dumber rule based format to cover 90% of the usecases, and then allow people to hook in anything they like via a trivial varlink call or so, i.e. via IPC. People could then use a language of their choice, implement some varlink method in it, bind the resulting tool to some socket via systemd socket activation, and you have all you need.
@dalias@Man2Dev@Foxboron Oh, that was misleading on my side. I meant not actually between containers, but merely from host to itself, and from host to container. i.e. no way up the tree, or sideways, if you so will.
@xexaxo CAP_SYS_NICE is wrong tool for the job. use RLIMIT_NICE instead.
I guess we could just raise that level to all session logging in via pam_systemd, so that they maybe can acquire nice level -5 without any complications if they like
Lazy mastodon: anyone knows if we can enumerate passed virtiofs instances (by tag) from inside a VM userspace?
(Asking because we are pondering to add systemd-virtiofs-generator which will automatically mount virtiofs tagged by some scheme to certain dirs to simplify things)
virtiofs certainly appears as a device in sysfs when enabled, but I am a bit puzzled whether there's any scheme to enum the passed devices from userspace. (the kernel keeps a linked list of them afaics, but userspace?)
We recently added a new document to the systemd website focussing on one specific facet of the service manager: the fdstore. A concept that people should really use more to facilitate "seamless" service restarts and various other things. Please have a look:
I just added a bunch of new entries to it (at the bottom). If you are looking for something to hack on (and have some kernel expertise, or would like to acquire it), would be more than excellent to work on those!
@osandov@brauner oh, i'd love if another attempt on this would be made. We currently hack around this in systemd, but that just makes the window where an aborted file update leaves files around very short but doesnt make it go away. Would be so good to get that properly fixed in the kernel.
@hughsie that bug report is a bit vague. The error messages are nothing i can really grok.
My educated guess is that this is about dbus-daemon vs. dbus-broker. Fedora uses the latter, conservative distros otoh still havent made the switch. The two daemons handle user name resolution in the policy differently, and this causes quite weird behaviour and in particular different behaviour between the two broker implementations. Dynamic users by their nature are transient and hence only...
@hughsie ... resolvable as long as the relevant service is up. The policy logic in the brokers arent ready for that, they assume everything is always resolvable.
There has been discussions on addressing this, but neither implementation is really making big jumps ahead, dbus land is kinda stuck it appears.
Tldr: dynamicuser atm is kinda incompatible with dbus.
@hughsie use always if its possible for the service in question. It's not really workable for dbus services right now for the mentioned reasons and for stuff that needs to run too early at boot or needs to establish mounts in the host mount table (since DynamicUser=1 implies mount namespacing).
Why should we trust our TPM's to store a secret? What proves the chip maker, U.S. government, or whoever else doesn't have a backdoor API or method to get them to give up our private key?
@purpleidea in fact you can even use the pcr measurements to make the system authenticate itself to you, before you type in the pw, so that you know for sure its really your unmodified laptop you are typing your secret into and not just a lookalike or a laptop that was backdoored while you were away. Tldr: no, the tpm stuff (when done correctly) should always improve security never worsen it. You make a variety of attack scenarios much harder if you bind things to the tpm, even if you...