HN user

noinsight

1,335 karma
Posts8
Comments331
View on HN

Put the phone in their pocket and it felt a press and went into edit mode and edited the lock screen.

This is why I hate the flashlight and camera buttons on the lock screen - which you can activate without unlocking. When you have your hands in your pockets during cold weather you’ll suddenly be ”filming”… I never use the camera on my phone anyway. Thankfully at some point they added support for removing them.

bypasses the TPM check

The caveat with this is that it will fail the check on subsequent version upgrades too and will refuse to upgrade.

Non-Enterprise editions are only supported for 2 years so your 25H2 (or whatever it is) installation will go sour in 2027.

Windows is not limited to accessing partitions through drive letters either, it's just the existing convention.

You can mount partitions under directories just like you can in Linux/Unix.

PowerShell has Add-PartitionAccessPath for this:

mkdir C:\Disk

Add-PartitionAccessPath -DiskNumber 1 -PartitionNumber 2 -AccessPath "C:\Disk"

ls C:\Disk

It will persist through reboots too.

We are also entering the age of "hey AI, take this repo, reimplement the same functionality".

Wouldn't you do this just against the/an API documentation? Interesting thought.

Orchestrate the renewal with Ansible - renew on the "master" server remotely but pull the new key material to your orchestrator and then push them to your server fleet. That's what I do. It's not "clean" or "ideal" to my tastes, but it works.

It also occurred to me that there's nothing(?) preventing you from concurrently having n valid certificates for a particular hostname, so you could just enroll distinct certificates for each host. Provided the validation could be handled somehow.

The other option would maybe be doing DNS-based validation from a single orchestrator and then pushing that result onto the entire fleet.

allow better network management

Yeah, this would definitely block that.

DNS-based (hostname) allowlisting is just starting to hit the market (see: Microsoft's "Zero Trust DNS" [1]) and this would kill that. Even traditional proxy-based access control is neutered by this and the nice thing about that is that it can be done without TLS interception.

If you're left with only path-based rules you're back to TLS interception if you want to control network access.

[1] https://techcommunity.microsoft.com/blog/networkingblog/anno...

Unix was very much made for multi user environments. ... The biggest security concern was making sure that everyone who was logged in was billed correctly.

I don't know about that... It doesn't even support multiple administrators. And you can't even distinguish between actions performed by the system itself and the administrative user.

Yes I know about sudo.

What do you need to do and what do the (even audit) logs say about who performed an activity whenever administrative activity happens?

But almost no one needs to write a policy.

But that's exactly what I would like to do! I've never seen a real guide for how to set up a policy for a custom daemon I wrote myself. Or when a specific software doesn't come with a policy.

Microsoft is like Google in this space.

The previous iteration got killed right when it could have started gaining traction due to Microsoft's shift to "cross platform" and PowerShell Core.

The previous iteration of the Local Configuration Manager for Linux was written Python while the Windows version was a distinct codebase entirely.

But even regardless of that I have zero confidence that Microsoft can break into this space and that the Windows culture would shift in this direction. The mentality is just not there with the typical (majority of) admins.

Actually, arguably Windows has some impressive security features unseen on any other mainstream OS, they're just not used by default and - realistically - would be hard to enable on general purpose / non-corporate computers.

For example, by comparison, Linux is in the stone age here.

Do you even need AV if untrusted code can't run in the first place?

* Application whitelisting - with just bare old AppLocker, Windows can be configured to only allow execution of trusted executables, DLLs and scripts by path, hash or software vendor (digital signature). Now, technically AppLocker is not a security feature, i.e. a hard security boundary.

The next level functionality, Windows Defender Application Control (WDAC) [1], however, is. I believe Microsoft was offering up to a $1M bug bounty for WDAC bypasses?

With WDAC kernel mode code integrity enabled, only trusted digitally signed kernel modules can be loaded into the OS kernel [2]. WDAC user mode code integrity provides the aforementioned protection AppLocker provides.

With AppLocker / WDAC enabled, the OS built-in script interpreters (Windows Script Host, PowerShell) either refuse to execute unsigned scripts completely or operate in restricted mode with reduced functionality.

- By comparison, Linux only has fapolicyd which is only supported on Red Hat and can only rely on path-based rules because binaries are not directly signed on Linux. None? of the common interpreted languages (Python, Perl, Ruby, Bash) on Linux support digitally signed scripts and locking down interpretation.

* Authentication material protection - Windows has Credential Guard [3] for protection of authentication material - Kerberos tickets and other material are placed in a separate container protected by hardware virtualization [2] and accessed via RPC so you can't dump process memory to compromise them. Even kernel level compromise is not enough.

- By comparison, Kerberos tickets on Linux reside as files on disk, SSH user & host keys reside as files on disk and loaded into sshd/gpg-agent memory, x.509 keypairs reside as files on disk & process memory etc etc. Wouldn't it be nice to have them protected somehow? To my knowledge, nothing exists for this on Linux.

[1] WDAC - https://learn.microsoft.com/en-us/windows/security/applicati...

[2] VBS - https://learn.microsoft.com/en-us/windows-hardware/design/de...

[3] Credential Guard - https://learn.microsoft.com/en-us/windows/security/identity-...