Recently posted comments

You could also make it available to things with NNP set, and when cloning children, the PRIV_KILL, then pass it around, send signals. These all checks happen when the flag is used during pidfd_open or clonefd or whatever.

Do you see other cases where it could be a problem?

AFAIK, the latter didn't run for DPL, did he?

And, btw, as you recommended to nix in another post, I searched through the first two pages of Google search results. No corresponding hits.

Best,
Joachim

For some reason X connection is sometimes used to check which DRI device driver should use, although in Multi GPU setups GPU used for 3D / display isn’t necessarily the correct one to use for video. It should be straightforward for driver to check directly which of the GPUs it actually supports, but no...

With FFmpeg one can specify the device with -vaapi_device (and with -qsv_device when using QuickSync backend).

Another reason for error could be trying to load wrong libva backend or load it from wrong place. That isn’t Wayland issue either.

Some what resistingly I changed pid_max to 999999 some months ago. With the 15 bit limit in use for decades I expected something to break. But luckily I have not observed any breakage (although I'm ready to believe those who say they have seen broken SW). Only (command line) user friendliness has suffered a bit. Most of the pids are 6 digits to remember. But hey, that's what I wanted...

It's indeed strange that the 15 bit limit has lived for so long. On the other hand in desktop usage and probably also in many server cases the process creation rate has not increased that drastically as many other performance parameters during the last 20 years.

It can't harm if the kernel hackers fix this issue in any case.When thinking about pid namespaces and mount namespaces involved we can just hope it doesn't get too complicated to be usable in real life...

If a user decides to format the drive / reinstall the OS in order to get rid of the attacker's persistence, this doesn't help with that, since the kernel is going to be replaced as part of that. At least with incomplete verified boot for only firmware, it's eliminating a form of stealthy attacker persistence where formatting / replacing the drive doesn't purge them presence. I don't think that replacing userspace without touching the kernel is a normal thing to do though, especially if even the initramfs is not verified, so an attacker can still persist via the boot partition alone. If everything in that partition is verified, then at least it reduced what needs to be replaced to purge an attacker from the system, although I just don't see it as reasonable to find an infection and then replace only userspace, since they are usually strongly paired together and there's no disadvantage to doing both at once.

You mention above that an implementation going much further like in Android means it isn't a general purpose computing device anymore, but how is this different? You can turn off verified boot on a Pixel just as you can turn off this feature, and right here is an example of a real world, common use case that is being wiped out in the name of security. I am a big fan of verified boot and attestation and I'm fully in support of having those aggressively implemented for nearly every use case, but I just don't see the gains coming with the loss of control in this case.

Even when people do try to submit code upstream, it's often blocked for arbitrary reasons. For example, an open source kernel driver won't be accepted if there isn't an open source userspace library for using it, and there are often very arbitrary blockers for other things.

So, consider if lockdown wasn't automatically enabled by rather was a sysctl toggled by early userspace, which was verified? And what if it wasn't so coarse, but rather more fine-grained, so that you can expose something to part of the userspace TCB while disabling it everywhere (i.e. like using SELinux). What is the distinction in terms of threat model between the kernel and core userspace processes like init? What does attacker gain by compromising the kernel in terms of harm to the user that they can't by compromising all of userspace? The only thought that comes to mind is the kernel can theoretically defend hardware that is known to be broken from them, but in practice I don't see the Linux kernel actually acting as a gatekeeper in terms of disabling access to hardware until it receives firmware updates fixing the vulnerabilities if that's even possible.

There needs to be a clear threat model and purpose behind a security feature for it to be useful. I would say the threat model for Android verified boot is preventing an attacker from persisting access after a compromise in a way that preserves the privileges needed to access data of arbitrary apps, etc. It also prevents them from persisting past the user doing a factory reset as a secondary thing. Users can wipe via recovery or safe mode boot even if the attacker persists as an accessibility service, device manager and all the other privileges accessible to normal apps. It also preserves enough of the application layer integrity for apps to chain from it with attestation, which is still fragile, but it's improving. So, for example, in https://github.com/GrapheneOS/Auditor I can chain trust from the OS in a way that allows meaningfully providing data from the OS about which device managers are enabled, etc. in a way that an attacker can't bypass without a verified boot bypass or re-exploitation of the OS on the next boot. The hardware attestation provides the OS version and patch level so they can't stealthily hold back updates to keep the OS vulnerable to their re-exploitation if a patch is shipped.

All I'm trying to say is that I don't think the boundary being drawn in this precise way as a hard-wired policy makes sense without it enforcing meaningful security properties / defending against a defined threat. It doesn't mean there's not a lot of useful work as part of it, I just don't think the way it's grouped together into coarse, hard-wired high level policies makes sense. I fully support most of the individual pieces of it, but I think it needs to be exposed differently, and without what I think is a meaningful secure boot model as the entire purpose of it.

Sure, although the ability to run native code from outside an apk dynamically is going to continue fading away (at least outside isolated_app) and that isn't part of the verified boot security model. It also really doesn't matter if the code is native. It's about reducing trust in persistent state to enforce meaningful security properties. It doesn't matter if the attacker can't inject native code if they can use interpreted code with the same privileges, or other trusted state allowing themselves to get to that point. The security model for verified boot is preventing an attacking from persisting with privileges beyond what a normal sandboxed app can do which preserves the OS security model including protecting apps from each other. It also enforces that a factory reset will purge the attacker's persistence, since that's implemented by wiping userdata. It's quite useful, and apps can chain the trust to themselves with the hardware-based key attestation feature in order to provide application-level security based on the verified boot process. This is being further improved in Android Q with a new property for apps to improve the chaining of security.

> Android can constrain that through significant reduction in attack surface because it's not a general-purpose operating system - you don't need to worry about someone taking advantage of a userland vulnerability in code running as UID 0 and then kexec()ing into a new kernel with an autostarting app if you don't support kexec() in the first place.

It doesn't make any sense to claim that it isn't a general purpose OS because it has a separation between the base OS and third party code with sandboxing for all third party code. It has nothing to do with general purpose computing or a general purpose OS. Someone can just as easily claim that by implementing this lockdown feature you are making it into a non-general-purpose OS by taking away control over the kernel. It's an arbitrary distinction that you're making and people are certainly going to be unhappy with having this feature in place. It's extremely arbitrary and doesn't provide them real security. At least with Android verified boot, you get real security advantages out of it. You're still taking away control over the system when this feature is enabled, but without giving something back. You want to draw a line between the verified base OS, with integrity preserved afterwards, and the non-verified portion, but by drawing the line at the kernel it's unable to enforce meaningful security properties improving actual security. It's only an internal bureaucratic security boundary based on the internal organization of the OS. An attacker controlling the entirety of userspace i.e. completely uncontained real root with no security policies is already a complete loss. The kernel pretty much just serves the needs of userspace. What is the real world use case for the security boundary being drawn this way rather than via policy set up by init?

> The goal here is building infrastructure to allow you to have as secure a boundary between userland and the kernel as possible while still allowing for general purpose computing. At the moment there's no good way to include any userland tooling in the TCB while still maintaining the characteristics of a general purpose Linux distribution.

The kernel doesn't do anything useful without userspace though, and the general purpose computing argument is bogus. If you think verifying and preserving the integrity a small base OS including init takes that away, so does doing it for the kernel. General purpose computing is not about an implementation detail like this. Functionality being inside or outside the kernel is an implementation detail that ultimately doesn't matter to end users. If you think it stops being a general purpose OS when full user control at runtime after it's booted is taken away, you've already done that with this feature.

You need at least some of userspace to be verified so that something is actually being protected. As long as you at least verify the initramfs and load a standard set of SELinux policies there, your policies can be enforced, but it's still unlikely that it will have any use unless you actually verify more of userspace from there. Even Android's verified boot has narrow security goals.

Verified boot can be extended to including the kernel line and initramfs, and from there it can be extended to verifying even a small portion of userspace like init and an initial set of security policies loaded by init which can enforce this kind of boundary without hard-wiring all this policy in the kernel.

4901 processes ought to be enough for most people.
If you raise pid_max to 99999 on small system and set these limits does it strongly reduce the issues?

Lager systems might need to increase pid_max further, and have bigger rlimits.

In either case it seems like it can mostly be solved with saner configuration.

But that behavior would be pretty awful -- which files you can access depending upon your current locale? There's a reason filesystems (including this ext4 proposal) store the mapping used when creating the filesystem...

> without *at least* a user-space proof-of-concept system.

Two have been mentioned already. Android has an overlay filesystem for local access, and samba implements it when exporting the filesystem over the network.

There's no purpose in using "short" to store PIDs when we have "pid_t" and using "char[6]" as string storage for a PID has always been a pretty bad idea. The print formatting that assumes six columns is ugly but not dangerous, and apparently people just don't care, as "vmstat" has had broken column widths for at least ten years (block IO per second and memory sizes are much larger than vmstat originally designed for).

/org/gnome/desktop/wm/preferences/raise-on-click

It was set to false (non-default value). I don't know how/when that got changed but setting it to default fixes my issue.

For the rest, as long as there is no easier way of taking over the kernel than loading wicked modules, agree. Though given the way people love to stuff things into the kernel which could be done in user-space - with perhaps a bit more effort - I think that there will usually be other ways available with not much extra effort.

I've just tried this with Epiphany (a Wayland app) in the background, and it works too! I've no idea why it doesn't work for you -- I don't think there are any options that could tweak this. Bug? Some shell extension (I have only one -- Transparent OSD)?

The annoyances I spoke of were more of the sort where a new window appearing under the mouse cursor gains focus. I think focus should always stay where it is while I'm not moving the mouse pointer. (This is fun when the Alt-Tab dialog appears under the mouse pointer -- when it disappears, the window under the pointer gets focus instead of whatever window I selected with Alt-Tab.)

No need to wonder why it's impossible to get useful restaurant recommendations these days.

Perhaps this is more of a feature than a bug but I much prefer the behavior of sloppy focus in X11.

Not related to sloppy focus, but another weird (annoying) thing that I haven't figured out is that when I start an app the icon doesn't immediately appear in the dock. It takes a few seconds (up to a minute) in Wayland. I'm using the "Dash to dock" extension, so perhaps this is a bug in the extension but, again, it works fine in X11.

When a traced process is killed by signal or `exit_group`, or does an `execve`, its threads exit in some unknown order. rr wants to clean them all up at once by `wait`ing for those specific threads but NOT receiving notifications for other threads it may be tracing. We currently have no way to do that. AIUI with pidfds we would be able to use, say, `poll` to wait for the exit notifications of a specific set of threads.

You might think we could handle`SIGCHLD` to know when notifications are pending for a traced thread, and use `waitpid` to grab the results for each traced thread after it exits, but that isn't reliable because multiple pending `SIGCHLD`s can be coalesced. Even with `signalfd` :-(.

This is a problem for libraries in general. If you have a library that wants to manage some child processes without interfering with other code (including on other threads) managing other child processes, that's really hard without pidfds.

You don't do anything like this really, you can actually set the process cloned using CLONE_PIDFD to deliver no signal to the parent on termination (by setting it to null), which means everyone having a copy of the same file descriptor can poll on it to know when it dies. That also means the process cannot be waited upon, which is what you want when you use this API from inside libraries.

It happens as a side effect of using descriptors, since the parent will get a readable instance (however it is still not clear to me this is something the patch author will support, here's to hoping that), it can pass a copy of its descriptor to others, then perhaps close it, and allow the other process to essentially poll on it, know when the process is gone, and get back the exit status.

The same could be done using references to external processes using pidfd_open, you pass a flag that requests the kernel to give you a readable instance, and if you're a real_parent or parent (as in ptrace terms), you get one. It also has the nice property of the mount namespace not being the one where you acquire pidfds, but limited to the scope of your PID namespace (which I think is a very important point that has been overlooked thus far).

Scoping the opening and adding a system call with extendable flags would allow you to lift checks in pidfd_send_signal to signall across namespaces, exactly because without userspace doing it on its own, a process can only open a pidfd to something it can address inside its PID namespace. It is otherwise a layering violation (literally) that I can use the mount namespace to circumvent this, if iy is opened up in the future. I also object to being able to peek into process state through such descriptors, that capability should be orthogonal, not bound to the pidfd, even if I have the authority to read through. *Therefore, using /proc dir fds comes with a big downside to all of this.*

The nice delegation model allows you to extend pidfd_open with, say, PRIV_KILL that allows you to bind CAP_KILL privs to a pidfd, assuming you have CAP_KILL in the owning userns, which would allow you to pass this pidfd and let the receiver signal across namespace boundaries without restrictions (it has to be opt-in as this is not what you want by default).

You could add a similar flag to bind ptrace privs of the opener, though that is a lot more involved and I have not mentioned it anywhere thus far.

Thus, you can think of the pidfd as a stable reference to the process, and such flags depending on the authority of the opener (if parent, readable, if CAP_KILL, killable, if CAP_SYS_PTRACE, ptraceable, etc) allow you to open up methods to operate on it, and since they are bound to the descriptor, it is limited in scope to the said process only. Such intent cannot be expressed when using /proc. It also does not play well with hidepid=2 (invisible dirs mean you cannot take a reference), and hidepid=1 (dirs you cannot enter mean you cannot reference threads you can see).

The whole reparent on fd-passing however is broken. There can be multiple processes keeping it open at a time.

I've used sloppy focus for many years, and I've switched to Wayland maybe a year or two ago. There are situations where it doesn't work the way I think it should work, but I think I remember them annoying me on X11 too?

One regression from Xorg that remains and is personally annoying to me is middle-click on the title bar doesn't reliably lower windows. (It works for legacy Xorg apps using Xwayland; doesn't for native Wayland apps.)

Seeing as it seems it can only be activated on an empty directory, the i-nodes would have to have space for two entries - the canonical form and the user form. Any file-system access converts to canonical and searches on both, but a collision on the canonical name will take the appropriate behaviour.

That might also provide a way for switching a used directory to case-insensitive - the canonical field would start out empty, but writing to the directory would do a canonical search and return an error if there was a collision. Be a bit messy though possibly.

Cheers,
Wol

The problem we faced then was exactly the problem of reparenting when the file descriptor is passed onwards via AF_UNIX. Especially when that is coupled with ptrace(), which appears to do a fake-reparenting to the tracer process. No one could explain to us back then what the issue was, so we couldn't fix and the matter was dropped.

Here's to hoping this feature is useful for userspace.

However there's an interesting thing here...you still really want a "human readable" and persistent identifier. With regular files, fds are obviously retrieved via...file names.

But this proposal is adding no such equivalent - /proc/<pid> doesn't solve the problem because it uses integers.

Now one of the core innovations of systemd was using cgroups as a way to just *group* processes. That model has further extended into modern container systems - e.g. in the model popularized by Docker, a "container" is a grouping of an image with cgroups, namespaces etc. Put another way...no one using e.g. Kubernetes really ends up thinking in terms of pids - you `kubectl delete pod/X`.

Back to cgroups...I think we can push admins and userspace more to thinking in terms of the cgroups. What if our identifiers for processes were more like (cgroup ID, u64)? And we had a system call that took that pair? It'd greatly ameliorate issues with pid reuse - at least you'd never end up killing a process in another cgroup.

We'd have /usr/bin/kill httpd.service/42 or so.

The proper way would be to assure userspace that pids (process uuids, process atoms, you name it) are never reused for system lifetime. If you have id, it's guaranteed to be the ID.

Whole 'pid' thing sounds more like hotel room numbers instead of guest identity.

This is on Arch with latest packages, the same VA-API patchset for Chromium as Fedora uses I believe.

mpv works fine under Wayland with acceleration, but Chrome fails to load libva and reports errors under chrome://gpu Log Messages at the very bottom.

/*
* A maximum of 4 million PIDs should be enough for a while.
* [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.]
*/
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

though uapi/linux/futex.h seems to imply that the actual limit is 30 bits

/*
* The rest of the robust-futex field is for the TID:
*/
#define FUTEX_TID_MASK 0x3fffffff

... will that help CISCO understand security issues better, or reduce the security in Duo?

This issue is a good example why public peer-review makes sense. You can't hide behind anyone else; marketing pushing for a poor solution can be pushed back more vocally. Which is why security products shouldn't be proprietary with a closed source code.

Lennart

So Linux cannot exchange data with MacOS and Windows?! PANIC!

Or put another way: if I show you that less than 1% of the population really wants or needs a case-insensitive filesystem, can I disregard your claims?

But wait! If you want to prevent the PID from being reused, and you're the one calling clone() in the first place, all you have to do is *not* call wait(), and then the PID will zombify in an entirely race-free fashion. That doesn't require the use of a pidfd at all. So the only "interesting" functionality we would be adding via a pidfd-that-holds-a-PID-open is the ability to transfer stewardship of a possibly-zombie process to a new "owner"(via SCM_RIGHTS over an AF_UNIX socket, or via fd inheritance), but without changing its PPID. That is such a niche usage that I'm not certain it's actually helpful, especially since you can create a subreaper via prctl(), and thereby actually reparent the process as needed.

(TL;DR: Because then it wouldn't be complicated and/or "interesting" enough to be worth doing.)

ugh this is too real...

This means *all* the overheads will truly need to be present only for those who actively *use* the system.

I honestly don't know how this is all going forward without *at least* a user-space proof-of-concept system.

I'm not saying that such a design is a good idea, it's just that I've seen it used.

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_prac... still seems like the best option, for anyone that cares about security and reliability, which I wish multiple governments and corporations recognized.

The main reason I stay on Xorg though is something much simpler: When I'm in a file manager, such as in nautlius, and I open a file in my IDE, I want the IDE to gain focus (so the IDE opens and appears on screen, or the IDE already being open appears on top). In wayland this doesn't work and I'm left in the file manager wondering why double clicking the file didn't work...before I realise it did open the file in the IDE, its just not in focus. :(

Alternatively, it would be an amusing hack to tell Skype that you've got an extra camera that's actually PipeWire. That would probably be a surprising UI, but I'm not sure it wouldn't be nicer than screen sharing normally is.

There's no real point in having secure boot enabled if you can load arbitrary drivers, so having users disable secure boot in order to load unsigned drivers is entirely aligned with the aim of the patches - the user has to actively acknowledge that they're disabling security functionality in order to achieve their goal. Users should definitely have the freedom to make that choice.

The goal here is building infrastructure to allow you to have as secure a boundary between userland and the kernel as possible while still allowing for general purpose computing. At the moment there's no good way to include any userland tooling in the TCB while still maintaining the characteristics of a general purpose Linux distribution.

1. Somebody, probably in PR, gets told that "the software is vulnerable to an attack... here's an example using curl."
2. Over repeated rounds of transoceanic communication between PR and eng, this gradually mutates into "Our software must block curl."
3. Somebody gets assigned the bug to "Block curl."
4. They protest that blocking curl is ridiculous and impractical. They get told that this is a mandate and they have to do it anyway. At no point is the word "security" used.
5. Engineer shrugs and codes a simple UA check, figuring that if the user is spoofing the UA, then blocking them is basically impossible anyway.
6. QA confirms that curl is blocked.
7. PR is pleased to see that eng has "finally" "fixed" the "bug" and announces it.

It sounded like they had loads of devs churning out garbage to loads of QA teams who repeatedly knocked things back until enough 'quality' had been tested into the code that it could be released... QA looked good for finding lots of bugs, and development looked good for fixing them all quickly, even though it was the same junk going round and round.

The user, maybe?

What about the use case where I type in a name in a picker, and it displays a bunch of matches?

Or what about the case where I typed in the name on the command line? Some of us still use a command line, you know ...

Cheers,
Wol

Having said that, it's great that progress is made.

Doing so may have a negative effect on your ability to obtain support service from Red Hat, though.

> I'm not sure you understood the purpose of the *

I've yet to meet someone who does. This looks like some pre-enlightenment practise where mentioning the name of a demon or deity conjures it.

Yet another reason not to buy a router that can't be re-purposed with OpenWRT.