@pid_eins@mastodon.social
@pid_eins@mastodon.social avatar

pid_eins

@pid_eins@mastodon.social

⛵ I write software. ⛵

This profile is from a federated server and may be incomplete. Browse more on the original instance.

pid_eins, to random
@pid_eins@mastodon.social avatar

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

pid_eins,
@pid_eins@mastodon.social avatar

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.

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@dalias We actually have an option for that in /etc/systemd/system.conf.

But I am not aware of any general purpose distro setting that.

And ideally we'd turn off the suid/fcaps logic already in kernel, i.e. compile the whole thing out.

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@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

pid_eins,
@pid_eins@mastodon.social avatar
pid_eins, to random
@pid_eins@mastodon.social avatar

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?)

pid_eins,
@pid_eins@mastodon.social avatar

@stefanha Ah, thanks for responding, much appreciated!

I filed this now:

https://gitlab.com/virtio-fs/virtiofsd/-/issues/128

uevent or sysfs attr would all work for us.

pid_eins, to random
@pid_eins@mastodon.social avatar

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:

https://systemd.io/FILE_DESCRIPTOR_STORE/

pid_eins, to random
@pid_eins@mastodon.social avatar

Reminder: we maintain a kernel feature wishlist here as part of the uapi group:

https://github.com/uapi-group/kernel-features

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!

pid_eins,
@pid_eins@mastodon.social avatar

@brokenix I have no idea of riscv, no of vmsplice, nor of dcas. Sorry. Simply the wrong person to comment on this.

pid_eins,
@pid_eins@mastodon.social avatar

@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, to random
@hughsie@mastodon.social avatar

Can any experts explain why DynamicUser in a timer works on Fedora, but fails on every other distro we've tried? Details in https://github.com/fwupd/fwupd/pull/6178 -- thanks!

pid_eins,
@pid_eins@mastodon.social avatar

@hughsie where precisely am i supposed to look where i can see logs/output where things fail? I am a bit lost on the PR.

pid_eins,
@pid_eins@mastodon.social avatar

@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...

pid_eins,
@pid_eins@mastodon.social avatar

@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.

pid_eins,
@pid_eins@mastodon.social avatar

@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).

pid_eins, to random
@pid_eins@mastodon.social avatar

The excellent CCC VOC people published the AllSystemsGo! videos from this week. Here's the UKI talk I did there:

https://media.ccc.de/v/all-systems-go-2023-185-unified-kernel-images-ukis-

Enjoy!

pid_eins,
@pid_eins@mastodon.social avatar

And here's my other talk, about TPM2 and Linux: https://media.ccc.de/v/all-systems-go-2023-186-linux-tpms

pid_eins,
@pid_eins@mastodon.social avatar

And so many more excellent other talks: https://media.ccc.de/b/conferences/all_systems_go/asg2023

purpleidea, to random
@purpleidea@mastodon.social avatar

Honest question:

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?

https://www.youtube.com/watch?v=0RSH3JXqShE

/cc @pid_eins

pid_eins,
@pid_eins@mastodon.social avatar

@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...

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea ... otherwise leave your auth flow as it was.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • ngwrru68w68
  • everett
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • rosin
  • GTA5RPClips
  • Durango
  • Youngstown
  • slotface
  • khanakhh
  • kavyap
  • DreamBathrooms
  • provamag3
  • tacticalgear
  • osvaldo12
  • tester
  • cubers
  • cisconetworking
  • mdbf
  • ethstaker
  • modclub
  • Leos
  • anitta
  • normalnudes
  • megavids
  • lostlight
  • All magazines