Microsoft Aims For Greater Script Execution Control On Linux

[HEL88]

Heki is Linux kernel has the hypervisor doing the HVCL things.

HVCL on Windows is available from 2015. Many companies already use it as mandatory for years. In W11 HVCL is enabled by default. Is very easy tu use so its so popular.

Do you use Heki?? Do you use EVM? When Heki become common in Linux world?

problem that the HVCL cannot check it own integrity either.

Secure boot.

[DeepDayze]

Agree! Hopefully they can reduce where linux is behind windows regarding security: https://madaidans-insecurities.github.io/linux.html

So maybe M$ will think of using Linux kernel to replace NTOSKRNL.EXE?

[F.Ultra]

I like how their slide in favor of implementing HCL under Linux is that Linux had 300+ CVE:s in 2022 of which 8 lead to code execution while if we look up Windows Server 2022 in the same time period had 422 CVE:s of which 130 lead to code execution...

[Jonjolt]

I don't know, the technical details but why not work on improving this in SELinux?

[oiaohm]

HVCL on Windows is available from 2015. Many companies already use it as mandatory for years. In W11 HVCL is enabled by default. Is very easy tu use so its so popular.

Do you use Heki?? Do you use EVM? When Heki become common in Linux world?

Heki is new. Linuxboot on server boards is not new.

There has been different methods at play here. Large parties in Server world with Linux instead of doing a hypervisor has been replacing the system firmware.

Secure boot.

Secureboot under HVCL on server windows could be Linuxboot.

There are known exploits against secureboot.

Linux kenrel before IMA/EVM can be validated by secureboot as well. But high end hardened Linux don't like secure boot.

There is differences in option on how this stuff should be done.

Heki is following the Microsoft idea of add a hypervisor and have generic possible exploitable signing keys in system firmware. Linuxboot is the route of by systems with firmware matched to company to low level attacks have to be created per company because each companies motherboards using the route has unique firmware approval.

Fun of recycling hardware.

[Rallos Zek]

Effuk off Lennart Poettering with your cancer!

And effuk off Micro$oft! You've ruined you're own operating system, do don't ruin ours!

[junkbustr]

Yet another example of M$ competitive strategy: Embrace, Extend, Extinguish.

[marlock]

script execution scope restrictions...

that sounds a lot like AD, Group Directives and whatnot

as a general concept I know this is something loads of corp IT admins like and use to manage worker machine fleets

historically it also probably made a lot of sense for a long time

but, despite my very-much-non-expert user (or should I say victim?) POV and overall lack of reading on the details of how the new proposal should work, it smells like it can quickly become a hot mess of incomplete restrictions because it comes from microsoft and with that name...

right out of the gate why say they'll only restrict scripts and not everything that needs to do operation X regardless of being a script or not? hopefully just a misleading name or me getting it all wrong

more importantly, in my very humble opinion that sort of thing (at least in Microsoft's hands alone) is great at giving IT higherups a false sense of corp security while sowing chaos at lower IT levels and end users working around these arbitrary restrictions to be able to conduct legitimate work at great expense while a professional hacker can easily bypass them and still hurt the company amidst the fuss

the most iconic case at my company is explorer.exe being forbidden from accessing folders and running executables with different credentials than the logged-in user... IT dept themselves run notepad.exe than use its file picker dialog instead because running with different (usually admin) credentials is sometimes necessary while remotely fixing user problems

as Joker once said to Batman: what doesn't kill you only makes you weirder

this is also exactly my experience with stuff like office365 and microsoft's cloud-based corporate user login infrastructure

there is a directive my company deemed important to opt into (I blame microsoft for even offering this POS option, obviously serving their own browser share interests more than anything) whereby I can't use MS Teams and other 365 suite web apps over Firefox on a mobile device

i have firefox in the win11 work machine as the default browser

i can legitimately use firefox at my personal linux desktop, even though IT doesn't fully recognize this as a safe environment to work from

i can legitimally use teams over microsoft edge on my personal smartphone (if I agree to unagreeable terms after login, which I won't)

...and I get logged-in successfully via Firefox or Google Chrome, to only then be greeted to "your corp has not allowed you to do this on this browser on a mobile device" kind of message

...but guess what happens if i switch the android firefox app to desktop mode before i log in?

yep, it just loads the damn app and works fine

so IT thinks this magic toggle does something useful, but all it does is hinder coleagues from doing legitimate mobile work, while any lamer or script kiddo can fake a user agent string and render it moot... heck, I found this by sheer accident!

And if the threat model is a hacked phone OS not managed by IT, what good can Microsoft Edge do to protect the company data in the browser in that system that Google Chrome and Firefox can't?!

[oiaohm]

script execution scope restrictions...

that sounds a lot like AD, Group Directives and whatnot!

Not really.

https://static.sched.com/hosted_files/lssna2023/80/2023-05-10%20LSS%20-%20Script%20execution%20control.pdf

Page 3 state the core issue.

./script.sh vs. sh script.sh

Of course Microsoft has over looked /usr/lib64/ld-linux-x86-64.so.2 some ELF binary that does not have a execute flag.

Someone need to work out a system for interpreters to use so that users can mark execuitables and scripts as do not execute and this is obeyed. If Microsoft wants to invest the time and money making it maybe we should not stop them.

[marlock]

Not really.

https://static.sched.com/hosted_files/lssna2023/80/2023-05-10%20LSS%20-%20Script%20execution%20control.pdf

Page 3 state the core issue.

Thanks for the better info!!!
Making interpreted scripts honour the execute flag seems like a much more reasonable goal than what I infered previously