[c-linkage]

It's pretty clear that the security models designed into operating systems never considered networked systems. Given that most operating systems were designed and deployed before the internet, this should not be a surprise.

Although one might consider it surprising that OS developers have not updated security models for this new reality, I would argue that no one wants to throw away their models due to 1) backward compatibility; and 2) the amount of work it would take to develop and market an entirely new operating system that is fully network aware.

Yes we have containers and VMs, but these are just kludges on top of existing systems to handle networks and tainted (in the Perl sense) data.

[OptionOfT]

> It's pretty clear that the security models designed into operating systems never considered networked systems. Given that most operating systems were designed and deployed before the internet, this should not be a surprise.

I think Active Directory comes pretty close. I remember the days where we had an ASP.NET application where we signed in with our Kerberos credentials, which flowed to the application, and the ASP.NET app connected to MSSQL using my delegated credentials.

When the app then uploaded my file to a drive, it was done with my credentials, if I didn't have permission it would fail.

[bigfatkitten]

Problem was that delegation was not constrained, which makes it even worse the oauth authorization sprawl we have now.

That ASP.NET application couldn’t just talk to MSSQL. It could do anything it liked that you had permission to do.

[gz09]

> It's pretty clear that the security models that were design into operating systems never truly considered networked systems

Andrew Tanenbaum developed the Amoeba operating system with those requirements in mind almost 40 years ago. There were plenty of others that did propose similar systems in the systems research community. It's not that we don't know how to do it just that the OS's that became mainstream didn't want to/need to/consider those requirements necessary/<insert any other potential reason I forgot>.

[jacquesm]

Yes, Tanenbaum was right. But it is a hard sell, even today, people just don't seem to get it.

Bluntly: if it isn't secure and correct it shouldn't be used. But companies seem to prefer insecure, incorrect but fast software because they are in competition with other parties and the ones that want to do things right get killed in the market.

[germinalphrase]

Are there other obvious tradeoffs, in addition to speed, to these more secure OS systems vs status quo?

[jacquesm]

Yes, money. Making good software is very expensive.

[bigfatkitten]

And developer experience.

Developers will militate against anything that they perceive to make their life difficult, eg anything that stops them blindly running ‘npm get’ and running arbitary code off the internet.

[anonzzzies]

Well yeah, we had to fix some LLM that broke things at a client; we asked why they didn't sandbox it or whatever and the devs said they tried to use nsjail; could not get their software to work with it, gave up and just let it rip without any constraints because the project had to go live.

[nyrikki]

There is a lot to blame on the OS side, but Docker/OCI are also to blame, not allowing for permission bounds and forcing everything to the end user.

Open desktop is also problematic, but the issue is more about user land passing the buck, across multiple projects that can easily justify local decisions.

As an example, if crun set reasonable defaults and restricted namespace incompatible features by default we would be in a better position.

But docker refused to even allow you to disable the —privileged flag a decade ago,

There are a bunch of *2() system calls that decided to use caller sized structs that are problematic, and apparmor is trivial to bypass with ld_preload etc…

But when you have major projects like lamma.cpp running as container uid0, there is a lot of hardening tha could happen with projects just accepting some shared responsibility.

Containers are just frameworks to call kernel primitives, they could be made more secure by dropping more.

But OCI wants to stay simple and just stamp couple selinux/apparmor/seccomp and dbus does similar.

Berkeley sockets do force unsharing of netns etc, but Unix is about dropping privileges to its core.

Network aware is actually the easier portion, and I guess if the kernel implemented posix socket authorization it would help, but when user land isn’t even using basic features like uid/gid, no OS would work IMHO.

We need some force that incentivizes security by design and sensible defaults, right now we have wack-a-mole security theater. Strong or frozen caveman opinions win out right now.

[Terr_]

> It's pretty clear that the security models designed into operating systems never considered networked systems.

Having flashbacks to Windows 95/98 which was the reverse: The "login" was solely for networked credentials, and some people misunderstood it as separating local users.

This was especially problematic for any school computer lab of the 90s, where it was trivial to either find data from the previous user or leave malware for the next one.

Later on, software was used to try to force a full wipe to a known-good state in-between users.

[tremon]

the security models designed into operating systems never considered networked systems

The security model was aimed at putting the user in control of the software they run. That's what general-purpose computing is: allowing the user to use the machine's resources for whatever general purpose they intend. The only protection required was to make sure the user couldn't interfere with other users on the same system.

What was never considered before is adversarial software. The model we're now operating under is that users are no longer in control of the software they run. That is the primary thing that has changed; not the users, not the network, but the provenance and accountability of software.

[SoftTalker]

Excuse me? Unix has been multiuser since the beginning. And networked for almost all of that time. Dozens or hundreds of users shared those early systems and user/group permissions kept all their data separate unless deliberately shared.

AI agents should be thought of as another person sharing your computer. They should operate as a separate user identity. If you don't want them to see something, don't give them permission.