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

eliasp, to proxmox
@eliasp@mastodon.social avatar

#Proxmox just generates a #UUIDv4 like
3b7d2d2c-3732-41db-a678-8bc4aeaf9155 as a secret for auth tokens? 😱
This looks a lot like a bad security practice to me, especially when RFC4122 says:

"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation."

#ITSecurity

pid_eins,
@pid_eins@mastodon.social avatar

@eliasp As long as v4 type uuids are generated based on a strong RNG (i.e. kernel one), they should be fine as secrets (assumed 122 bit entropy is sufficient for your needs).

v4 uuids are just 15.25 bytes of randomness after all, which seems fine for many purposes.

pid_eins, to random
@pid_eins@mastodon.social avatar

When pondering whether we should start linking to some external library in systemd, I usually spend some time looking at the library's sources, to understand the quality of the code. While coding style differences are fine, there are certain red flags that make libraries unsuitable for use in systemd, or that indicate questionable quality of the code.

Red flags like this are for example absence of OOM guards on malloc(), absence of reasonable error propagation,

pid_eins,
@pid_eins@mastodon.social avatar

placement of too much state in global variables or TLS (instead of maintaining clean context objects), obvious TTOCTTOU races around file use, open coded structures, absence of symbol prefixing and so on.

But there's one red flag that I want to write about today, that's just so annoying, because it's not widely understood to be the devil's work: use of ELF constructurs/destructors.

In ELF/gcc you can mark functions as ELF constructurs or destructors. Functions marked like that…

pid_eins,
@pid_eins@mastodon.social avatar

… will be automatically called whenever the shared library they are placed in is loaded into a process (which means at process startup, before main(), or at dlopen() time) or when they are unloaded from a process (which means at exit() time, or dlclose() time).

At first, from the outside the concept seems kinda OK: it has this C++'ish RAII feeling to it to: whenever a library is initialized in can initialize some fields, and whenever deinitializes it can release them again.

pid_eins,
@pid_eins@mastodon.social avatar

But of course (I guess like various C++ feaures), it's also terrible if people actually start using this IRL. In particular in systemd this is has brought a repeating theme of breakage to us.

The systemd service manager (aka "PID 1") runs very early at boot, it is after all typically the first userspace process invoked on a system. This means it initially runs in a very minimal execution context, for example /proc/ and /sys/ are typically not mounted yet, there's no /tmp/, and nothing else.

pid_eins,
@pid_eins@mastodon.social avatar

When systemd's main() function is started it then goes through a careful process of setting things up, i.e. establishing mounts, making things writable, loading security policies, initializing certain devices, RNGs, and so on, loading configuration and many many other things. This is carefully scheduled to be done in the right order, since after all we cannot assume that things are already set up for us, we have to do the setup ourselves after all.

pid_eins,
@pid_eins@mastodon.social avatar

But of course ELF constructors fuck that all up, because they get started before main() does its first step even, after all. It takes any control away we have in scheduling precisely when to do what.

And people do terrible things in ELF constructors: load configuration, check if kernel APIs are available (which typically means looking at /proc/, /sys/ or some other API VFS), pre-opening some fds, and so on. All these are things you really don't want to do before things are properly mounted, …

pid_eins, (edited )
@pid_eins@mastodon.social avatar

…, labelled, initialized and so on. One prominent library which we do link against that used to do horrible shit like that, is libselinux btw. They fixed much of it, but still use ELF constructors/destructors these days, and they really shouldn't.

Now you might say that not all projects are systemd, that we are a special case, but there are many other problems with it:

There's no ordering defined in which constructors/destructors are called. Or at least not a useful one: it's "topoligical".

pid_eins,
@pid_eins@mastodon.social avatar

Which means that constructors are invoked in the order the shared libraries are loaded in, and if shared libraries have dependencies, they are first loaded "down the tree". But that sucks hard, because libraries tend to have interdependencies, non obvious ones at that, and cyclic ones too! And that means you might end up calling functions from libs whose constructors haven't run yet, or whose destructors already ran.

Then, various libraries (including systemd's) use "-z nodelete", …

pid_eins,
@pid_eins@mastodon.social avatar

… or are loaded via RTLD_NODELETE (for various reasons). The effect of that: the ELF destructors they provide will never be called, and what's worse, the destructors of any depending lib will never be called either, ever).

What's worse: it's not clear which thread invokes the constructors/destructors even. It might be the main thread, or some other thread, because dlopen() is used from it, directly or indirectly. And other code might run in parallel with your constructor/destructor hence.

pid_eins,
@pid_eins@mastodon.social avatar

Relevant C projects nowadays tend to have CI systems that run everything in their codebase through valgrind and memory sanitizers provided by the various compiler suites. This is an additional headache when ELF destructors are used: whether memory is leaked or not cannot be determined correctly from inside a process if you basically have to exit first to get the resources are actually released by the ELF destructor.

And then, various projects tend to open/close fds in their ELF…

pid_eins,
@pid_eins@mastodon.social avatar

…constructors. But that sucks hard, because in so many cases system level C code must be able to ensure that all fds are closed (for example, in systemd we require this when we load MAC policy, so that all fds are definitely labelled properly, and for many other reasons) at some time, but if "hidden" fds are kept open, that cannot be reasonably closed unless a library is unloaded then things are just unworkable.

Anyway, there are other reasons ELF constructors/destructors are shit, …

pid_eins,
@pid_eins@mastodon.social avatar

… but let's stop this for now (there's more, really, for example sandboxing, and ELF const/dest really make an awful combo; or blocking syscalls in them will make dlopen() hang, or fricking locking in them is a desaster), and summarize:

ELF constructors/destructors run at the worst times, are not reasonably schedulable, run from arbitrary contexts, in abitrary threads, too early, and too late, maybe not at all, and not intstrumentable reasonably for analyzers. Hence, fuck them.

pid_eins,
@pid_eins@mastodon.social avatar

But enough of the expletives, let's talk a bit of what to do instead?

I think good C library design is always built around some kind of opaque context object (possibly multiple), that all relevant functions provided by the library get passed in as first argument. This context object should be allocated by one library function and destroyed by another, but key really is that the library is "dormant" until that constructor is explicitly called by its user, and "dormant" again…

pid_eins,
@pid_eins@mastodon.social avatar

… when the destroy function for the relevant contexts is called again.

And that's really all I'd ask for. This is great, because it means consuming code can carefully schedule when and in which context it wants to start making use of the library, and thus when it shall be initialized, and when it doesn't need it anymore, and when it shall be deinitialized again.

pid_eins,
@pid_eins@mastodon.social avatar

@GabrielKerneis they probably just don't.

libselinux is a really bad offender not just regarding this red flag. I guess the reason they get away with it, is because they come from a time where CIs/test suites were not a thing yet, and they are so low level in our dep tree, that everyone just accepts their fate and ignores the red flags.

zygoon, to random
@zygoon@fosstodon.org avatar

During the last Canonical engineering sprint someone mentioned it is possible to know if a terminal has light or dark a background and adjust colors to match, so that application text remains readable.

Yesterday I took a stab at this and implemented a trivial crude version that works on both MacOS terminal and GNOME terminal, but not the Windows terminal.

Here you can see it work both locally and across ssh to another OS and CPU architecture.

Demonstration of terminal background color probing utility. The code runs locally on MacOS, correctly detecting dark vs light terminal background. The demo continues remotely with the same application running on a Linux server over ssh, still correctly observing “dark mode”.

pid_eins,
@pid_eins@mastodon.social avatar

@zygoon in systemd we have this C code for this:

https://github.com/systemd/systemd/blob/main/src/basic/terminal-util.c#L1725

swsnr, to Steamdeck
@swsnr@mastodon.social avatar

My laptop screen broke, so I figured I could use my as replacement. Didn't want to loose Steam OS, though, it's a gaming device after all.

So I bought a SanDisk SD card for 35€, and used to flash a workstation disk image onto it. Took a few days to understand what packages I need for the full workstation experience, but in the the end the process was surprisingly smooth.

pid_eins,
@pid_eins@mastodon.social avatar

@triskelion @swsnr building initrds with mkosi is a thing. And what i'd recommend.

pid_eins, to random
@pid_eins@mastodon.social avatar

Kernel breaking userspace episode nr. 43858262:

https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66

Hacking around it:

https://github.com/systemd/systemd/pull/32892

pid_eins,
@pid_eins@mastodon.social avatar

And yes I am pretty sure they should revert the kernel change. Departing needlessly from the option name the other file systems give this is already wrong. But breaking all current systemd versions on new kernels just for the fun of it is extra wrong.

Note that I actually do think it's ok if kernel folks break interfaces every now and then if done for a good reason and if userspace is prepared. But here neither is the case. And my main beef here is that they claim they wouldnt do it ever...

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Jeremy Allison writes:

'" The data shows that “frozen” vendor kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux created by Greg Kroah-Hartman. '"

https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca sure, but then the rule is not "we never break userspace" but more "move fast and break things, and sometimes revert where people protest too loudly".

I mean, that's fine by me, but maybe they should communicate it like that then.

The thing is that removing a widely documented mount option is very obviously a compat breakage. You cannot discount that. It's not just a "mistake" to remove something like that, it's an obvious attempt to break compat.

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca

Actually, the exact relevant rule is "WE DO NOT BREAK USERSPACE", all in uppercase.

https://lkml.org/lkml/2012/12/23/75

I find the sound of that mail quite different from your much weaker "let's maybe undo the worst shit if people complain too loudly"... And of course "uh, sometimes we fucked up so hard, we cannot fix it anymore, let's add a new api instead" (which is what happened in the block device capabilities/media change api).

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca

(again, I actually find it OK if API is broken from time to time, just be honest about it, and communicate properly, and do a bit of research first. Don't claim that uppercase extremism and then do not even superficially follow through)

hyc, (edited ) to random
@hyc@mastodon.social avatar

Gag, puke, retch... This sample code for communicating with is abominable. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html

From gratuitous use of superfluous language features (a cleanup handler, for a single fd, srsly?) to inappropriate use of standard POSIX APIs (using connect+write on a socket that only sends one message and then gets closed, really?) Older compilers don't even support a cleanup attribute, and this code is used as a model of portability??

's version is better.

pid_eins,
@pid_eins@mastodon.social avatar

@hyc @wednesday well, any compiler used on any Linux from the last decade or more supports the cleanup stuff. And that pretty much matches systemd's intended audience.

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.

ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).

pid_eins,
@pid_eins@mastodon.social avatar

@shoragan ssh over rs232, eh?

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