Hacker News Reader

Comment by tinus_hn | Hacker News Reader

> You might want this when running unrelated processes in userspace, for example.

When are you not? Why have security and process isolation if all processes are considered related?

You might perhaps have a setup where trusted users are running trusted code, can guarantee* a lack of malicious intent, and primarily want the user-and-process-segregation system to prevent a single failure of a single process from affecting anyone else.

You might conceivably have this in a corporate environment (I do).

For the vast majority of systems that do run untrusted code, including web browsers, this mitigation is probably appropriate.

Perhaps the word “might” here could be upgraded to “probably”?

*for some arbitrary value of “guarantee”

So you run everything as root, or your setup would work just as well if you did?

How is that comparable? Running everything as root is a) asking for accidents; b) a different class of problem.

You still want to run as a regular non-root user, possibly different users. The key difference to the mainstream use case is that you're looking to minimise the impact of bugs and failures, rather than manage security and combat malicious actors/code.

For this particular use-case, you might well consider that you don't need to patch for meltdown and spectre given the perceived risk/performance tradeoff for the current patches.

I think you misunderstand. The statement "when running unrelated processes in userspace" probably means, when running multiple threads under the same process id. Threads are "lightweight processes" in linux parlance (e.g. linux treats each "thread" as process, and then deals with the fact that some of them share memory). What they are saying is that this instruction is - for example - for a browser (a userspace process) to clear the branch prediction cache after running untrusted javascript on another thread.

At work we use the same account on some remote boxes to run trusted code. This works as we trust each other and follow the agreement not to mess with co-worker files unless previously agreed. Yet process isolation allows to kill run-away processes without affecting other processes or shells.

That is the same mindset as users who say they have nothing to hide so they don’t need to use a strong password.

Unless your computer is air-gapped you can’t trust it to run only the code you expect.

The decision on how much effort you expend to secure your particular system(s) often comes down your perception of risk and reward (and it's worth emphasising that word perception too).

There's usually a cost associated with greater security[0], and generally a balance that is struck. You can argue whether a particular system should lean further towards security, or further towards lower-cost, but ultimately there'll be a judgement call.

I'd suggest there isn't a single correct answer for this.

[0]whether in actual dollars, ease-of-use for users, time-to-market or possible reduction in feature set

Indeed, many people make wrong decisions based on incorrect assumptions.

At present time using separated user account gets very little from a security point of view judging by number of local privilege escalation bugs that are constantly found for common Linux setups.

In our case if the malicious code will run on those shared boxes, it implies either a bug in ssh or an Ubuntu software update bringing malicious code or an attack through a hacked computer of one of the users. In either case protecting other users from the effect of malicious code on those boxes will be the least of our worries. Yet the separated accounts do have substantial usability overhead.

Reply on news.ycombinator.com