"Now that's curious..."

I personally doubt SAK/SAS is a good security measure anyways. If you've got untrusted programs running on your machine, you're probably already pwn'd.

The whole windows ecosystem had us trained to right click on any Windows 9X/XP program that wasn’t working right and “run as administrator” to get it to work in Vista/7.

Unfortunately it doesn't take any display server into consideration, both X11 and Wayland will just get killed.

These days, things have gotten far more reasonable, and I think we can generally expect a linux desktop user to only run software from trusted sources. In this context, such a feature makes much less sense.

   1. Snapshot the desktop
   2. Switch to a separate secure UI session
   3. Display the snapshot in the background, greyed out, with the UAC prompt running in the current session and topmost

Clever way of dealing with the train wreck of legacy Windows user/program permissioning.

It's not just visual either. The secure desktop is in protected memory, and no other process can access it. Only NTAUTHORITY\System can initiate showing it and interact with it any way, no other process can.

You can also configure it to require you to press CTRL+ALT+DEL on the UAC prompt to be able to interact with it and enter credentials as another safeguard against spoofing.

I'm not even sure if Wayland supports doing something like that.

Is there an offset. I could have sworn things always seemed offset to the side a little.

It sounds like yet another violation of the Line of Death principle (in context of OS, not browser).

https://textslashplain.com/2017/01/14/the-line-of-death/

I actually wrote a fake version of RMNet login when I was in school (before Windows added ctrl-alt-del to login).

https://www.rmusergroup.net/rm-networks/

I got the teacher's password and then got scared and deleted all trace of it.

> Example output of the SysRq+h command:

> sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(v) show-blocked-tasks(w) dump-ftrace-buffer(z) dump-sched-ext(D) replay-kernel-logs(R) reset-sched-ext(S)

But note "sak (k)".

IO_Uring is still a pale imitation :(

io_uring didn't change that, it only got rid of the syscall overhead (which is still present on Windows), so in actuality they are two different technical solutions that affect different levels of the stack.

In practice, Linux I/O is much faster, owing in part to the fact that Windows file I/O requires locking the file, while Linux does not.

https://learn.microsoft.com/en-us/windows/win32/api/ioringap...

Although Windows registered network I/O (RIO) came before io_uring and for all I know might have been an inspiration:

https://learn.microsoft.com/en-us/previous-versions/windows/...

You can see shims for fork() to stop tanking performance so hard too. IOUring doesnt map at all onto IOCP, at least the windows subtitute for fork has “ZwCreateProcess“ to work from. IOUring had nothing.

IOCP is much nicer from a dev point of view because your program can be signalled when a buffer has data on it but also with the information of how much data, everything else seems to fail at doing this properly.

On the surface, they are as simple as Linux UOG/rwx stuff if you want it to be, but you can really, REALLY dive into the technology and apply super specific permissions.

You have a hardened Windows 11 system. A critical application was brought forward from a Windows 10 box but it failed, probably a permissions issue somewhere. Debug it and get it working. You can not try to pass this off to the vendor, it is on you to fix it. Go.

And then you get security product who have the fun idea of removing privileges when a program creates a handle (I'm not joking, that's a thing some products do). So when you open a file with write access, and then try to write to the file, you end up with permission errors durig the write (and not the open) and end up debugging for hours on end only to discover that some shitty security product is doing stupid stuff...

Granted, thats not related to ACLs. But for every OK idea microsoft had, they have dozen of terrible ideas that make the whole system horrible.

This makes writing robust code under those systems a lot easier, which in turns makes debugging things when it goes wrong nicer. Now, I'm not going to say debugging those systems is great - SELinux errors are still an inscrutable mess and writing SELinux policy is fairly painful.

But there is real value in limiting where errors can crop up, and how they can happen.

Of course, there is stuff like FUSE that can throw a wrench into this: instead of an LSM, a linux security product could write their own FS overlay to do these kind of shenanigans. But those seem to be extremely rare on Linux, whereas they're very commonplace on Windows - mostly because MS doesn't provide the necessary tools to properly write security modules, so everyone's just winging it.

Also, as far as I know Linux doesn't support DENY ACLs, which Windows does.

Wouldn't the o::--- default ACL, like mode o-rwx, deny others access in the way you're describing?

Here is kernel dev telling they are against adding NFSv4 ACL implementation. The relevant RichAcls patch never got merged: https://lkml.org/lkml/2016/3/15/52

I see what I misunderstood, even in the presence of an ALLOW entry, a DENY entry would prohibit access. I am familiar with that on the Windows side but haven't really dug into Linux ACLs. The ACCESS CHECK ALGORITHM[1] section of the acl(5) man page was pretty clear, I think.

[1] https://man7.org/linux/man-pages/man5/acl.5.html#ACCESS_CHEC...

Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.

What?! I was doing kickstart on Red Hat (want called Enterprise Linux back then) at my job 25 years ago, I believe we were using floppies for that.

BTW, we managed to get the earlies history of the project written down here by one of the earliest contributors for anyone who might be interested:

https://anaconda-installer.readthedocs.io/en/latest/intro.ht...

As for how the automated installation on RHEL, Fedora and related distros works - it is indeed via kickstart:

https://pykickstart.readthedocs.io/en/latest/

Note how some commands were introduced way back in the single digit Fedora/Fedora Core age - that was from about 2003 to 2008. Latest Fedora is Fedora 43. :)

Preseed is not new at all:

https://wiki.debian.org/DebianInstaller/Preseed

RH has also had kickstart since basically forever now.

I've been using both preseeds and kickstart professionally for over a decade. Maybe you're thinking of the graphical installer?

- There does not seem to be a way to determine which machines in the fleet have successfully applied. If you need a policy to be active before doing deployment of something (via a different method), or things break, what do you do?

- I’ve had far too many major incidents that were the result of unexpected interactions between group policy and production deployments.

1. cloud-init support was in RHEL 7.2 which released November 19, 2015. A decade ago.

2. Checking on Ubuntu, it looks like it was supported in Ubuntu 18.04 LTS in April 2018.

3. For admining tens of thousands of servers, if you're in the RHEL ecosystem you use Satellite and it's ansible integration. That's also been going on for... about a decade. You don't need much integration though other than a host list of names and IPs.

There are a lot of people on this list handling tens of thousands or hundreds of thousands of linux servers a day (probably a few in the millions).

Without Proton there would be no "Linux" games.

It would be great if Valve actually continued Loki Entertainment's work.