Default-Accept philosophy make it easier for millions of holes to open up ag first and you spend entire IT budget locking down things you don't need but not the ones you don't see that needs closing.

Default-deny is one time IT expenditure. And you start poking holes to let things thru. If that hole is dirty, you plainly see that dirty hole and plug it.

All that also equally applies to CPU designers.

Firejail provides a very usable implementation with default profiles for lots of programs.

I've been using this since the PyTorch exploit [1].

Most programs don't need access to large parts of your filesystem or network.

[1] https://pytorch.org/blog/compromised-nightly-dependency

Let’s use Apple as an example, as they tend to do major transitions on a regular basis.

So, let’s say that the top tier already approved the new security mode(l).

Now, how to do it?

My understanding is that most if not all APIs would have to be changed or replaced. So that's pretty much a new OS, that needs new apps (if the APIs change, you cannot simply recompile the apps).

Now, if you expose the existing APIs to the new OS/apps, then what's the gain?

And if you don't expose them, then you basically need a VM. I mean, I don’t know Darwin syscalls, but I suspect you might need new syscalls as well.

And so you end up with a brand new OS that lives in a VM and has no apps. So it's likely order(s?) of magnitude more profitable to just harden the existing platforms.

It also requires rewriting all your apps.

It also might require hardware support to not be significantly slower.

"Just sandbox each app" has much fewer barriers to entry, so people have been doing that instead.

And systems like Android have been working with discrete permissions / capabilities, because they were able to start from scratch in a lot of ways, and didn't need to be compatible with 50 years of applications.

https://www.spritely.institute/

https://files.spritely.institute/papers/spritely-core.html

Back in 70s and 80s computers didn't contain valuable information to care about and there was no Internet to transmit such information. So, adding some sort of security elements in operating systems had no sense. In these years modern operating system were first developed - Unix, Dos, Windows. Since then many architectural decisions of these operating systems weren't revised in order to avoid breaking backward-compatibility. Even if we need to break it to achieve better security, no one is ready to make such sacrifice.

There are projects of operating systems with focus on security, which are not just Unix-like systems or Windows clones. But they can't replace existing operating systems because of network effects (it's unpractical to use a system nobody else uses).

We live in a capabilities based world. Most of my outlets give 120 volts at 15 amps and deny access to the whole power grid. We don't have to have certified electricians check each and every device before connecting it to power.

When I want to pay for a purchase I have a number of possible economic capabilities from 1 cent to 100 dollars. I don't have to risk accidentally draining my bank account to pay for a soda.

On our GUI oriented systems, file selections could automatically handle capabilities and the user might not even notice a difference. We shouldn't have to risk our computer just to run a program.

Give that all of this was worked out in the early 1980s, I strongly suspect a conspiracy to deliberately delay the implementation of capabilities by the US NSA and other Intelligence agencies. Ironically this choice resulted in horrible long term consequences for US National Security.

It is much like the object-capability model described on Wikipedia, and it is neither a blacklist model nor a whitelist model. A whitelist model would have a list (or other criteria) of what is permitted, but for a better capability-based system, it works differently.

My idea involves capabilities (which can include proxy capabilities as well; i.e. it is not necessarily what you asked for, but you can send/receive messages anyways) which can be sent and used like the object-capability model, including as the initial message (instead of using command-line arguments, file descriptors, etc, it uses the "initial message"; this is like the "initial conditions" described on Wikipedia), which should include some capabilities otherwise it cannot do any I/O and will be automatically terminated (before the program gets a chance to run) if no debugger is attached. (Unlike the standard object-capability model, there is no "endowment" (at least at the level of the operating system, although programming languages might have this feature); the capability does nothing by itself, but the process that created it can receive messages that itself and/or other processes send to it and use them for whatever that capability is intended to mean.)

Some benefits of a proxy capability system includes that many other things become unnecessary, since they can be done with proxies, such as: finer permissions than the capabilities normally allow, adding print preview to a program that does not have that feature (but that is able to print), simulating error conditions, testing if the date/time handling of a program would work correctly on February 29 (or some other date, or a leap second, etc) without needing to change the clock on your computer, accessing resources on another computer as though they are local (and vice-versa), etc.

You might be able to pass capabilities using the command shell like how on UNIX you can use pipes, but in this one you would pass capabilities instead (as well as the ability to create your own).

> I guess one objection is that people don't want to manually configure security.

In many ways, reasonable defaults can be configured, and some things can be configured automatically, although it would still be possible to manually set them to whatever you want them to be.

> if you select a file using a system-provided file picker it would automatically grant access to that file, as access is explicitly authorized

Nevertheless, there are problems with such things, especially if you try to add them to existing systems. For example, a program might require access to additional files depending on the one accessed (either referenced by those files or by a modification of the original file's name (e.g. the journal file in SQLite)), configuration files and command-line arguments, etc. You would also need to consider such things as popen (many of my programs use it, with a command specified by the user at run time or specified in a configuration file).

In a new operating system design you could also change the file system model as well, in order to help with this (I had ideas about how to do this, too).