Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The browser is the sandbox

aifoc.us

Post reply on HN
Print view View original

131–140 of 202 posts

Re: The browser is the sandbox

#131

Post by nesarkvechnep »

nextaccountic wrote: post #49
ijustlovemath wrote: post #18

I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good deal of customization in concert,and by their nature, are fairly low cost.

Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not suff…

There's FreeBSD's Capsicum. It's a full-blown sandboxing mode and capability framework. Unfortunately, Linux didn't adopt it and chose chaos.

Re: The browser is the sandbox

#132

Post by surajrmal »

curt15 wrote: post #125
nextaccountic wrote: post #49

Earlier quoted context omitted.

Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not suff…

>And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.

Android sandboxing works in spite of the underlying security model, not because of it. It's also really selinux that does a lot of heavy lifting.

Re: The browser is the sandbox

#133

Post by TingPing »

cobolexpert wrote: post #96
layer8 wrote: post #94

Earlier quoted context omitted.

> It makes web apps first class productivity applications. They won’t be first-class as long as native UI still has the upper hand.

In which way does native UI have the upper hand, do you think? To me it seems like a lot of users are largely indifferent to this aspect (e.g. so many applications nowadays being Electron/browser based). If browsers keep gaining capabilities then it seems like this gap will get even smaller.

I’ve never used a webapp that felt nicer than native software, it’s always very clearly a compromise.

Re: The browser is the sandbox

#134

Post by TingPing »

ijustlovemath wrote: post #42
ape4 wrote: post #36

Earlier quoted context omitted.

cgroups are part of whats used to implement docker and podman

True, and they do indeed offer an additional layer of protection (but with some nontrivial costs). All (non-business killing) avenues should be used in pursuit of defense in depth when it comes to sandboxing. You could even throw a flatpak or firejail in, but that starts to degrade performance in noticeable ways (though I've found it's nice to strive for this in your CI).

Namespaces are very lightweight though? Like single digit overhead.

Re: The browser is the sandbox

#135

Post by simonw »

TingPing wrote: post #133
cobolexpert wrote: post #96

Earlier quoted context omitted.

In which way does native UI have the upper hand, do you think? To me it seems like a lot of users are largely indifferent to this aspect (e.g. so many applications nowadays being Electron/browser based). If browsers keep gaining capabilities then it seems like this gap will get even smaller.

I’ve never used a webapp that felt nicer than native software, it’s always very clearly a compromise.

I can't tell what's a web app and what's native these days. Are you sure you can?

Re: The browser is the sandbox

#136

Post by surajrmal »

viraptor wrote: post #58
vbezhenar wrote: post #52

Earlier quoted context omitted.

Linux kernel is ridden with local privilege escalation vulnerabilities. This approach works for trusted software that you just want to contain, but it won't work for malicious software.

Ridden? There are issues from time to time, but it's not like you can grab the latest, patched Ubuntu LTS and escalate from an unprivileged seccomp sandbox that doesn't include crazy device files.

The Linux API surface is massive. And the fact it's written on C leaves lots of room for vulnerabilities. I don't think you need to reach for a VM, but without a slimmer kernel interface, it's difficult to trust the kernel to actually uphold its required duties in the face of adversaries. This is why folks push heavily for microkernels. Chrome needs to work incredibly hard to provide reliable sandboxing as a result.

Re: The browser is the sandbox

#138

Post by naikrovek »

This is the kind of thing that the browser should not need to do. This is the kind of thing that the operating system should be doing. The operating system (the thing you use to run programs securely) should be securing you from bad anything, not just bad native applications.

A large part of the web is awful because of all the things browsers must do that the operating system should already be doing.

We have all tolerated stagnant operating systems for too long.

Plan 9's inherent per-process namespacing has made me angry at the people behind Windows, MacOS, and Linux. If something is a security feature and it's not an inherent part of how applications run, then you have to opt in, and that's not really good enough anymore. Security should be the default. It should be inherent, difficult to turn off for a layman, and it should be provided by the operating system. That's what the operating system is for: to run your programs securely.

Re: The browser is the sandbox

#139

Post by TingPing »

simonw wrote: post #135
TingPing wrote: post #133

Earlier quoted context omitted.

I’ve never used a webapp that felt nicer than native software, it’s always very clearly a compromise.

I can't tell what's a web app and what's native these days. Are you sure you can?

I'd have a very good hit rate, it mostly comes down to knowledge of toolkits. There are native apps that use their own toolkit, mostly written in Rust these days, and they always are worse than traditional toolkits (accessibility, respecting platform settings, visually fitting in, etc). That same issue applies to webapps typically.

Re: The browser is the sandbox

#140

Post by surajrmal »

pjmlp wrote: post #116
rcarmo wrote: post #40

I don't buy it. It might be very useful for a few use cases, but despite all the desktop automation craze and "Claude for cooking" stuff that is inevitably to follow, our computing model for live business applications has, for maintainability, auditability, security, data access, etc. become cloud-centric to a point where running things locally is... kind of pointless for most "real" apps. Not that I'm not excited ab…

COM is pretty much alive, it is the main delivery mechanism for new Windows APIs since Windows vista, and in the context of your remark powers UI Automation framework. I have a DDE book somewhere, with endless pages of C boilerplate to exchange a couple of values between two applications on Windows 3.x.

I'm not sure new windows APIs use COM as people remember it. Nowadays they are written against WinRT, which is arguably an evolution of COM.
Post reply on HN