@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

@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

@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

@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

@xexaxo i dont really grok why just making the gpu prio follow the nice level isnt enough. I mean in absence of detailed io sched and cpu sched configuration both schedulers follow the generic nice level too. So why not do the same for gpu scheduling?

Or from the opposite PoV, when would you want a process that gets prio on the gpu but is scheduled with low prio on cpu & io? At least on the typical desktop cases it sounds unnecessary to set more than a single generic nice level to me.

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 @jamesh @mariusor and what's even worse. they are permanent: file ownership/ACL entries are persistently made on some inode, and there's no scheme to clean that up again (unless some – brittle – logic cleans this up manually). Moreover if you have access to an inode you basically have access to it forever, just by keeping an fd open.

UNIX access control works for simple, relatively static, non-interactive cases, but Polkit is precisely supposed to fill the gap where that's not enough.

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

@dalias @jamesh @mariusor

UNIX access controls suck though, since they control access to objects, not operations. And they are incompatible with potentially interactive authentication. Both of these things are what Polkit brings to the table: you authenticate actions, and you can allow them to require re-authentication by a user, interactively.

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

@polyna @dalias yes, it would.

In systemd we frown on suid binaries, we do not allow them in our own code.

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

@suqdiq there are plenty special purposes cases where people did this (I mean, the NNP option in systemd's configuration file exists precisely for those cases, and was added as result of a request from one). However, what I am asking for here, is that a generic Linux distro goes for this, and kills suid/fcaps for good.

pid_eins,
@pid_eins@mastodon.social avatar

@xexaxo https://github.com/systemd/systemd/issues/29446

mjg59, to random
@mjg59@nondeterministic.computer avatar

Hurrah recording of my Linux Security Summit talk on per-process hardware-backed secret management is up: https://www.youtube.com/watch?v=cMwQD0jtUfU

pid_eins,
@pid_eins@mastodon.social avatar

@mjg59 here's another idea: generate the hibernation encryption key already during early boot (i.e. any time before you allow userspace to do the first TPM interaction), keep it in mem (i.e. kernel keyring or so) Bind the key to PCR 0..7 + PCR 9. Then measure some separator into PCR 9, to make the key unretrievable by userspace.

Now you have the guarantee that userspace cannot retrieve the key, nor gen one anymore, but as long as the same boot path is booted the key will be avail to the kernel

pid_eins,
@pid_eins@mastodon.social avatar

@mjg59 then attach a quote of the same pcrs to the hibernation image. And some nonce that binds image and quote together. That would mean the same boot path is necessary to generate and use a hibernation image.

pid_eins,
@pid_eins@mastodon.social avatar

@mjg59 i mean, expecting that you can update your firmware or kernel in the middle of a hibernation cycle is kinda broken idea I am sure.

pid_eins,
@pid_eins@mastodon.social avatar

@mjg59 hmm, so the hibernation thing, what i never grokked: isn't it entirely sufficient to just bind encryption to a secret locked to PCRs 0…7? that's a very simple policy that just says: if you want to unlock the hibernation image you have to boot the same system with all the same components, including the kernel?

I mean, usually the PCR brittleness issue is what makes policies like that unrealistic in reality, but in a simple hibernation/thawing cycle that shouldn't be as much of a problem.

hughsie, to random
@hughsie@mastodon.social avatar

The UEFI Forum just published my proposal for creating a firmware SBoM!

You can see it here https://uefi.org/node/4424 -- comments most welcome.

pid_eins,
@pid_eins@mastodon.social avatar

@hughsie @bluca i.e. this stuff:

https://trustedcomputinggroup.org/resource/canonical-event-log-format/

That said, there's also the "RIM" spec, but I am not aware of anyone implementing it, and it's way over the top if you ask me:

https://trustedcomputinggroup.org/resource/tcg-pc-client-reference-integrity-manifest-specification/

I'd rather have a simple JSON-CEL file with the expected measurements.

pid_eins,
@pid_eins@mastodon.social avatar

@hughsie @bluca

So for my prediction stuff I want the measurements, not the results so much. i.e. I want to be able to recognize stuff in the event log, and for that it's crucial to know what was measured there as individual hashes, not just the result.

And I want all PCRs that firmware might influence. Which is a lot, basically 0…6.

(And for the SecureBoot policy update it would make sense to have the same data for PCR 7 btw).

My favourite format would be a subset of the TCG JSON-CEL.

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

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.

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.

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