Per-application users on desktop

Flatpak. Technically it uses namespaces, not different users, but it's going for that kind of security approach.
I think it does something where applications can only access files if they're selected with a flatpak-blessed filepicker.
It works a bit erratically in my experience and applications need to be specially packaged for it.

When I mean multi-user processing, I mean multiple users simultaneously using the system. This is multiple user profiles where only one user profile is active at any given time.

But do you actually use that on desktop? What are use cases?

Privilege separation, because Unix is kind of terrible about permissions and doesn't care about much beyond which user you are. It's the most practical hack to avoid giving applications unrestricted access.

Just use firejail.

firejail.wordpress.com/

Android does the same by default.
Not sure why you said

Firejail sucks and is insecure because SETUID and user namespaces :D

If you provide PoC maybe I can fix it for you :)

no, read on how insecure setuid and user namespaces are.

Look look there COULD be a bug somewhere! I use this other software that has me convinced there are no bugs! I can finally relax now..

It's called Qubes, but it goes further. Instead of launching applications under new user, it launches them under new OS.

firejail vs apparmor vs tomoyo vs selinux vs insecure X server ITT in 10...

I didn't.

Nothing about COULD, but there is no safe way to do setuid and unpriv user namespaces.
The code quality of firejail is also garbage so plenty of bugs to find probably.

yeah that's what I said, this is too extreme for me (and your average user, I guess), I don't think NSA is after me personally

well someone else did then, and you two are contradicting each other.

what else is viable except just running the fucking Android on the desktop?

That's fucking stupid. Linux already has support for process sandboxing and private namespaces. Start using the OS features retard

You're a meanieface. But you're right.

Using different usernames for privsep was always a misuse of the feature anyway. User accounts were for time-sharing, not security.

M-x burden-of-proof

I believe you're looking for AppArmor.
It's not quite what you described but it fills the niche.

Use docker or kubernetes

How in the fuck are namespaces insecure retard? They completely isolate global system resources like file systems, mounts, PIDs, UIDs, fucking anything. Programs can make their own container and become root there without screwing things up for everyone else. You can nest multiple init systems in multiple PID namespaces.

Elaborate, you fucking faggot.

Yes. Linux kernel hackers have been working on namespaces functionality for decades, it'd be a shame not to use it because some portable libc doesn't support it.

lwn.net/Articles/531114/

There's also capabilities-based authorization, which literally everyone should be using so that if your application is compomised attacker can't invoke the privileges you dropped. It literally makes system calls fail.

You don't need fucking docker to do any of this. If you make a namespace, the global system call privileges you dropped are restored for your namespace only. It works nicely.

The Qubes or Subgraph distros are closest to such a compartmentalization concept that I'm aware of.
Qubes uses virtualization, and Subgraph uses sandboxing of each application.

unpriv user namespaces have so many CVEs and the code is so complex.
github.com/subgraph/oz/issues/11#issuecomment-163396758
grsecurity disables unpriv user namespaces by default.

It has a long track record of bugs and there are lots of tricky things you can do with unpriv user namespaces.
github.com/xairy/kernel-exploits/blob/master/CVE-2017-7308/poc.c

Here is a PoC that abuses namespaces to gain priv escalation.
Even KSPP advises to disable user namespaces lmao.
kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls

...

There is a fix pending making it "safer" though but no idea if it will land.
openwall.com/lists/kernel-hardening/2017/12/05/13

It is the fault of namespace because a normal user can't get CAP_NET_RAW.
So if the user disable user namespaces he wouldn't be vulnerable to all kinds of garbage bugs.

thus advertising namespaces as a security feature is just retarded.

The vulnerabilities were already there before, namespaces just gave people an avenue to exploit them that they didn't have before. All these CVEs and the posts detailed in depend on root. It's not that namespaces are insecure, it's that root was never secured in the first place because people assumed getting root was the end game of owning a computer. Not using namespaces is just mitigation; the same exploits are possible on host root, the only difference is if you're on host root you don't need to exploit anything anymore.

It's amazing in my opinion. People are fixing bugs they wouldn't even have found otherwise because root was always assumed to be trusted.

That looks nice, but it will just end up mitigating vulnerabilities present in other kernel subsystems. It'd be better to simply fix those.

lmao, user namespaces are not secure.
And yet they seem to be advertised as security feature.
The whole point was to point out that user namespaces are NOT secure, not that those vulnerabilities were already there.

Not really, the bugs were already there and would been a minor issue regarding exploitation wise, the bugs would have been fixed regardless.
The biggest bug in those stories are that you can gain capabilities with a unpriv user namespace.

Fixing bugs is a never ending story and its better to mitigate the classes of bugs than having to fix em all.
.t kernel developer.

Who?

No, it's the rest of the kernel that isn't secure. User namespaces just give processes access to those systems in an isolated manner. Make those systems secure instead so that processes can't overwrite kernel memory through them.

Exactly.

Were people aware of these defects before namespaces came along and made them exploitable? Doesn't look like it. Why didn't they fix them?

Not a problem if your process is isolated. The real problem is it can exploit other buggy kernel subsystems. You're basically saying "well then since the kernel systems are buggy, processes shouldn't be allowed to call upon them at all", thereby mitigating everything and denying all blacklisted functionality as well.

I'm impressed by this discussion. You surprise me in a positive way Holla Forums.

then starting to use root for something else is a dumb fucking idea, from practical PoV.

I agree on that. Root is the cause of the vast majority of problems here. I've been looking all over for a while now and I can't find much involving the user namespacing mechanism itself, the closest I've found is: lkml.org/lkml/2015/12/12/259 It still involves root though.

Turns out this root thing isn't just my opinion:

utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems

This is fucked up, but it's not namespace's fault. People neglected other code because they assumed only root would ever touch it and now they're reaping the consequences.

Can people prevent namespaced processes from gaining CAP_SYS_ADMIN? This might be more sensible and targeted mitigation strategy than just disabling namespaces altogether because of uncertainty.

yeah, that's the key point. this should not happen IMO.

No, I don't agree on that point. Why are some parts of kernel OK to expose while others are not? Makes no sense.

I think it's great this code is being exercised in a way that will lead to identification and patching of vulnerabilities.

The actual bug was not discovered because of namespaces but made easier to exploit.
It actually was a minor bug because you already need to be root to exploit it but because of user namespaces you could exploit it as a normal user.

There is no isolation on x86 see meltdown & spectre.
Actualy isolation would have to be hardware and only a few architectures have a better isolation model.

No but those bugs weren't a big deal anyway if namespaces didn't exist you couldn't exploit them from a normal user since it can't get those capabilities.

No, it's the rest of the kernel that isn't secure. User namespaces just give processes access to those systems in an isolated manner. Make those systems secure instead so that processes can't overwrite kernel memory through them.

Except user namespaces aren't isolating anything really, there is still lots of information in /proc and /sys to do all kinds of cheeky stuff.

Yea there is lol. You just have to store things in different address spaces. It slows things down a bit but solves the problems.

Proper implementation of isolation on x86 is why AMD is immune to meltdown and not Intel.

AMD is still vulnerable to Spectre which has the same effect

Why is there even a CAP_SYS_ADMIN to begin with? Aren't capabilities supposed to be fine-grained? It's a literal >hurr can do anything capability. Linux/POSIX can't limit capabilities based on parameters either...

Sprectre isn't X86 specific, which is what you were implying. PPC, ARM and many other architectures also suffer from sprectre, not just AMD.

Meltdown neither, since arm is also affected on their upcoming line of processors.
ppc64 isn't affected by meltdown because of hashed page tables to seperate user/kernel address space.
grsecurity implemented PTI with UDEREF apparently.
I'd rather see it fixed in hardware like ppc64 has that would be much better than having software patches applied to the OS.

as already said, because they weren't tested for a lot of years and you can't expect everyone to catch up immediately, or at all, this is a huge fucking project written in C.

for example?

No. I'm implying process isolation is all fucked unless you put everything in different address spaces.

The namespace is insecure.
Firejail is so insecure (and someone have pointed out that code was not quality).

So how do you compartmentalize your applications? I want better security, especially concerning the web browser.
I was actually using firejail, thinking it would enhance my sec. So what should I do? Create a special user for the browser, and only browse through lynx because applications can access each other in X?

Seriously, the solution seems to only be Templos, with networking support, and go full ring 0.

Let my paint it like this for you. Even though we talk shit about firejail using namespaces. It's not like you can prevent any userspace program to create a fucking namespace and exploit your ass anyway. You see the PoC against namespaces posted earlier did not require firejail to work.

The problem is the attack surface of namespaces, not a program like firejail utilising the namespaces.. because well, any program could do that if they wanted to pwn you. Use firejail rather than nothing and totally fucking isolate in (not impenetrable either) VM if you do stupid shit.

unsage

Thanks you for the explanation. I don't really know how linux works at the low level. I should start to read the appropriate books.

you can use macOS; Cocoa doesn't have such baby problems.

reported.

wow, how nice that you also told me.
really scared me. 10/10

You're kidding, right?

Is there no way to reduce the attack surface? As in >>875814:

The only way is to disable it completely