oneplane

How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.

Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.

What are you even talking about. Every M1 Mac and earlier runs Linux. Even all the way back to PowerPC.

Granted, the M1 and up are not 100% covered yet (driver-wise), but they aren't EOL either. And if they were, Linux would still run anyway. Take a 20 year old Mac and you'll run Linux just fine. 10 year old Mac, Linux still runs fine. Take an M1 and it's a joy to use with Linux. Taken an M2 and it will boot and you can be pretty sure it will run very well long before it's EOL too. And even if it's EOL, it's not going to prevent you from running Linux later.

As for the PC example: definitely EOL problems there. Try getting your EDK2-based UEFI stack patched on an old computer. At some point you won't be getting certificate updates and if you either forget to install a local override or if the vendor didn't add it, you're SOL, especially on laptops where you can't disable secure boot.

Since SIP, it's MDM with DDM and you can basically leave engineers be local admins as it has no impact on the system state anymore.

I'd rather go back to bare metal than use Azure.

Those local options exist, and have been around forever, but the problem is nobody is doing it without cutting corners and with pay-as-you-go elasticity (and the 'call an API, get a VM instantly' effects that go with it).

Most on-prem deployments were trash and a lot of them still are. Not because it couldn't be better but because it's easier to just have some random hypervisor department do this work manually and not do the work to create it as an internal product. Even VMware with vrealize failed and that's about as 'customisable cloud platform in a box' as COTS enterprise software can get.

Maybe it's because IaC and APIs were just not in the vocabulary of the average system integrator or on-prem operating team (it's still lots of clickops and copy-paste).

Not really, some of the IP is core to the product and it cannot function without it. In theory if you do something like come up with a complete replacement for EUV, you could, but everyone with deep pockets has already been trying to do that without success. Same goes for the supply chains, most companies (including ASML) don't manufacture everything themselves; so components that come out of the US would need non-US suppliers, which don't always exist.

I suppose it's a case of 'technically possible, realistically infeasible'.

A more likely scenario might be either a from-scratch not-as-good machine that you can source locally (supply-chain wise) or a novel finding (which is hard to predict if it will happen and if so, when).

Which is why I wrote about running the exact UI that was referenced, with the same window server, window manager and desktop environment.

That statement makes no sense. X11 works fine on macOS and running it in rootful mode with Gnome essentially works the same way it would work on an OS that uses the Linux kernel.

Granted, it will not integrate with anything hardware-wise by itself (unless there's a package for it - if not, macOS still handles it, and Aqua/Quartz will keep running in the background anyway), but if what you wanted was something that is KDE or GNOME running with its own WM on its own X11 server, doing the exact same thing you'd get if you're running a Linux distro, that's been natively possible for over 15 years.

If a power user loses their power based on what GUI happens to be in front of them, how much of a power user was the power user to begin with?

It does, it's called FreeIPA (or RedHat IdM). The only GPO parts it doesn't do are those that are not related to policy in the IAM sense (i.e. configuring some application related thing). There's other systems for that, just like on Windows you practically never run GPO without anything else. On top of that, you can pay RedHat or Canonical to host it all for you on any cloud or non-cloud.

Oh yeah, you got the same process down pretty much yourself, wasn't an RTFM dig or anything like that. It was more aimed at others who might end up here, more tools, more better!

It's interesting how with some systems/engineering thinking you'll pretty much always get there in the end anyway, which is also why articles like yours are pretty neat. (sadly, not everyone takes the time to write things down and share them these days)

There is a lot of documentation from Apple on how all of this works, but this is indeed expected behaviour. A way to make this smoother would have been:

  1. Doing the password reset
  2. Reboot straight back into recovery
  3. Update your new password back into your old password
  4. Boot into macOS, your default keychain will unlock but you'll still have to re-authenticate to iCloud since your machine-user identity combo will no longer match with what iCloud expects. (not sure if this is part of Octagon Trust, but there are various interesting layers to this)

There are a number of much more in-depth technical guides and specs, but just listing out random articles (or the Black Hat talk(s)) would probably rob someone of a nice excursion into platform security.

Run it in a restricted VM, which is not joined to AD and cannot talk to it either. PAM will not save you, either will Airlock Digital or something like ATP or anything else like it.

Software for running VMs is free.

Giving users local admin rights is a massive security risk we can't take.

Sounds like you made your endpoints into pets and bastions, that's an architecture that is guaranteed to fail. Work towards a design where the endpoint no longer matters.

That online builder is very cool, well done!

I've been trying out similar things to help internal teams to use systems and languages like Rego (for Open Policy Agent) to have a visual and more 'a la carte' experience when starting out, so they don't have to jump straight to learning all syntax and patterns for a language they might have never seen before.

When they shrank the disc it just became minidisc ;-) But that was technically MO, not just optical. And: it was in a cartridge so I suppose they really should have called it minidisk.

Don't enable anything you don't need. Use the OS-native priority modes; i.e. no Slack messages after 18:00, no general message notifications unless from specific contacts, disable web browser notifications universally etc. no notifications for unknown sources (seems to be an issue in some countries).

It also really depends on how you perceive the alerts on a device; some people have lots of feelings when they see a dot or a number on an icon, others might not care or give it any attention. If such things are a distraction for you, turn them off. Unless they give you value or have an important meaning, they are not worth your attention.

Depending on your hardware/software vendor, it might be capable of synchronisation between multiple devices so you don't end up getting notifications anyway, and it might have multiple profiles with time boxes, or location-aware or event-aware profiles. Some of them are self-learning (to various degrees of usefulness), but either way, reduce the device to what you need it for.

I think the comment mainly pointed out the distinction between education using digital methods, vs. educating about digital things.

It's not a counterpoint, it's a display of your factually incorrect statement.

In other words, you're completely fucked if you brick your install. I consider iBoot a direct user-hostile downgrade from UEFI for this reason.

That's a bit of a creative perspective, isn't it? You have no control over the UEFI implementation of your vendor, same can be said for AGESA and ME, as well as any FSP/BSP/BUP packages, BROM signatures or eFused CPUs. And on top of that, you'll have preloaded certificates (usually from Microsoft) that will expire at some point, and when they do and the vendor doesn't replace them, the machine might never boot again (in a UEFI configuration where SecureBoot cannot be disabled as was the case in this Fujitsu - that took a firmware upgrade that the vendor had to supply, which is the exception rather than the rule). For DIY builds this tends to be better, Framework also makes this a tad more reliable.

If anything, most OEM UEFI implementations come with a (x509) timer that when expires, bricks your machine. iBoot2 is just a bunch of files (including the signed boot policy) you can copy and keep around, forever, no lifetimer.

Now, if we wanted to escape all this, your only option is to either get really old hardware, or get non-x86 hardware that isn't Apple M-series or IBM. That means you're pretty much stuck with low-end ARM and lower-end RISC-V, unless you accept AGESA or Intel ME at which point coreboot becomes viable.

Only if you boot into macOS and connect it to the internet. iBoot2 never changes by itself, you, the user, decides if you want to boot into recovery or macOS and run an update.

So can Apple stop signing new iBoot2 versions? Sure! And that sucks. But it's a bit of FUD to claim that Apple at arbitrary points in time is going to brick your laptop with no option for you to prevent that.

Granted, if you boot both macOS and Asahi, then yes, you are in this predicament, but again, that is a choice. You can never connect macOS or recovery to the internet, or never boot them.

Gee, another "we did not need cloud, so by not using cloud, we stopped spending on something we did not need"-story. Duh. The real story is why someone who doesn't need cloud services starts using them anyway.

If you need it, use it, if you don't need it, don't use it. It's not the big revelation people seem to think it is.

The problem was that the user's credentials were revoked but because the root account was a shared credential it wasn't revoked. Was the break-glass account also a user-specific account, it would have fit in with any 'revoke anything for user XYZ' workflow instead of being a root account edge-case.

So, in short, this would likely have prevented this, as the normal off boarding for user-bound credentials worked out fine already.

Not using root means not bypassing policies. There is no way to not bypass all policies. So yes, never using root makes that issue go away completely.

As for all the other stuff: what it does is it creates distinct identities with distinct credentials and distinct policies. It means that there is no multi-party rotation requires, you can nuke the identity and credentials of a specific person and be done with it. So again, a real solution to a real problem.

No, a massive amount of CloudTrail logs.

You don't need the root account, unless you need to bypass all policies. In such a scenario, you a use the root access reset flow instead, reducing standing access.

As for other flows (break glass, non-SSO etc), that can all be handled using IAM users. You'd normally use SAML to assume a role, but when SSO is down you'd use your fallback IAM user and then assume the role you need.

As for how you disable the root account: solo accounts can't, but you can still prevent use/mis-use by setting a random long password and not writing it down anywhere. In an Org, the org can disable root on member accounts.

This is just a Windows VM with extra tooling. Makes it look slick, doesn't make it "Windows apps on Linux".

Similar projects exist for gaming for example Looking Glass, which also uses a Windows VM on KVM (the "Windows in Docker" thing is a bit of a lie, Windows doesn't run in the container, Windows runs on KVM on the host kernel).

UX wise, this is similar to RAIL.

That's not to say that this isn't neat, but it's also not something new (we still have two flavours: API simulation/re-implementation and running the OS [windows]). If this was a new, third flavour, that would be quite the news (in-place ABI translation?).

You don't need to be in the Apple ecosystem to buy an Apple TV and only use non-Apple services.

The only thing that will probably suck is the lack of things like MiraCast and Google's Casting stuff, but you could use third party AirPlay software (still free IIRC) to stream whatever you want if you want to use screen mirroring.

These days people tend to use their media boxes as App Launchers for other services anyway, so it doesn't really matter that much anymore.

If the long-lived token is actually a private key that is non-retrievable and the secrecy and origin is attested by a HSM, I'm fine with that.

That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.

It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.

AWS has no such thing. It also is not an alternate either way since the owner of the first payment method would have this in an MPA, not in a member account, and in AWS, member accounts are not considered payers and any payment methods are ignored.

The article makes a variety of claims, some of which can be dismissed because they factually do not exist with AWS, and some of which cannot be verified at all. But precedent shows that when your middleman in a savings scheme drops out, you are screwed, and that is what happened here.

That doesn't make this fun, and it would be better if everyone had a personal account manager, but that's not the reality of today.