[–]▶ No.875435>>875446 >>875448 >>875460 >>875594 >>875616 [Watch Thread][Show All Posts]
Is there any existing GNU/Linux distro (or *BSD, whatever) that is configured by default to execute each userland application under a different "user" and does that seamlessly? So as to not cause massive PITA for the user but gain safety advantages (each application may only touch what it's allowed to touch and nothing more)
Similarly to how Android does that, but supporting real desktop-tier software, like Audacity, GIMP, programming IDEs, etc.
Configuring that myself is not an option, it's a fucking minefield and I'm not an expert in system administration, I'm a regular code monkey so I will absolutely miss something critical or just fail completely
▶ No.875437>>875438 >>875466
Android only has to support one user at a time. There's no multi-user processing on an Android computer. This is how Android can get away with that system. Traditional Unix systems don't work that way.
▶ No.875438>>875442 >>875453
>>875437
Wrong, recent versions of Android have some support for multiple users, as in multiple people.
▶ No.875442>>875444
>>875438
Can you point me to the API documentation for this.
▶ No.875444>>875445 >>875453
>>875442
https://support.google.com/nexus/answer/2865483?hl=en
this is what I could immediately find.
not sure about API, which one do you mean?
▶ No.875445>>875453
▶ No.875446>>875447
>>875435 (OP)
I think this is not compatible with X, because apps can access each other through that. Android uses SurfaceFlinger which is more like Wayland.
▶ No.875447
>>875446
Perhaps that's true, but I am completely fine if X has to go.
▶ No.875448>>875449
>>875435 (OP)
There is almost no security advantage to running everything as a different user vs using cgroups with docker or another system.
▶ No.875449
>>875448
>vs using cgroups with docker or another system
shouldn't using users be more memory efficient?
If I only cared about security and nothing else, I could go with Qubes OS but that's pretty extreme.
▶ No.875450
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.
▶ No.875453>>875457
>>875444
>>875445
>>875438
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.
▶ No.875457>>875458
>>875453
>I mean multiple users simultaneously using the system
But do you actually use that on desktop? What are use cases?
▶ No.875458>>875466
>>875457
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.
▶ No.875466>>875497
>>875458
Android does the same by default.
Not sure why you said >>875437
▶ No.875474>>875480 >>875606
>>875460
Firejail sucks and is insecure because SETUID and user namespaces :D
▶ No.875480>>875482
>>875474
If you provide PoC maybe I can fix it for you :)
▶ No.875482>>875485 >>875593 >>875606
>>875480
no, read on how insecure setuid and user namespaces are.
▶ No.875485>>875511
>>875482
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..
▶ No.875487>>875535
It's called Qubes, but it goes further. Instead of launching applications under new user, it launches them under new OS.
▶ No.875490
firejail vs apparmor vs tomoyo vs selinux vs insecure X server ITT in 10...
▶ No.875497>>875535
▶ No.875511
>>875485
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.
▶ No.875535
>>875487
yeah that's what I said, this is too extreme for me (and your average anon, I guess), I don't think NSA is after me personally
>>875497
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?
▶ No.875549>>875587
That's fucking stupid. Linux already has support for process sandboxing and private namespaces. Start using the OS features retard
▶ No.875587>>875606
>>875549
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.
▶ No.875593
>>875482
>no, read on how insecure setuid and user namespaces are.
M-x burden-of-proof
▶ No.875594
>>875435 (OP)
I believe you're looking for AppArmor.
It's not quite what you described but it fills the niche.
▶ No.875597
▶ No.875606>>875617 >>875633
>>875474
>>875482
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.
>hurr its not secure
Elaborate, you fucking faggot.
>>875587
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.
https://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.
▶ No.875616
>>875435 (OP)
>Is there any existing GNU/Linux distro (or *BSD, whatever) that is configured by default to execute each userland application under a different "user" and does that seamlessly?
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.
▶ No.875617>>875620 >>875642
>>875606
unpriv user namespaces have so many CVEs and the code is so complex.
https://github.com/subgraph/oz/issues/11#issuecomment-163396758
grsecurity disables unpriv user namespaces by default.
▶ No.875620>>875632
>>875617
It has a long track record of bugs and there are lots of tricky things you can do with unpriv user namespaces.
https://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.
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls
▶ No.875632>>875636
>>875620
>CVE-2017-7308
>bug in some networking code allows DoS and privilege escalation
>only exploitable if given CAP_NET_RAW by superuser
>namespaces let you become local superuser and give yourself the capability
>it's somehow namespace's fault
▶ No.875633>>875648
>>875606
There is a fix pending making it "safer" though but no idea if it will land.
http://www.openwall.com/lists/kernel-hardening/2017/12/05/13
▶ No.875636>>875638 >>875642
>>875632
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.
▶ No.875638>>875642
>>875636
thus advertising namespaces as a security feature is just retarded.
▶ No.875642>>875649 >>875796
>>875636
>>875638
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 >>875617 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.
▶ No.875648>>875649
>>875633
That looks nice, but it will just end up mitigating vulnerabilities present in other kernel subsystems. It'd be better to simply fix those.
▶ No.875649>>875651 >>875657
>>875642
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.
>>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.
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.
>>875648
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.
▶ No.875651
>>875649
>.t kernel developer
Who?
▶ No.875657>>875877
>>875649
>The whole point was to point out that user namespaces are NOT secure
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.
>the bugs were already there
Exactly.
>and would been a minor issue regarding exploitation wise, the bugs would have been fixed regardless.
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?
>The biggest bug in those stories are that you can gain capabilities with a unpriv user namespace.
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.
▶ No.875741
I'm impressed by this discussion. You surprise me in a positive way /tech/.
▶ No.875796>>875814
>>875642
>People are fixing bugs they wouldn't even have found otherwise because root was always assumed to be trusted
then starting to use root for something else is a dumb fucking idea, from practical PoV.
▶ No.875814>>875847 >>875903
>>875796
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: https://lkml.org/lkml/2015/12/12/259 It still involves root though.
Turns out this root thing isn't just my opinion:
https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems
>The problem is that even when everything works the way the theory has it,
>user namespaces still expose a lot of code in the kernel to normal users that was previously only really accessible to root.
>That code has not necessarily been thoroughly hardened against various sorts of nasty things,
>so if you can find some issue with some part of it you can then leverage access to it from a user namespace to turn what was a 'root can damage the system, big deal' issue into an 'anyone can do nasty stuff to the system' big deal issue.
>The actual bugs are not in user namespaces, but user namespaces enable access to them by making a lot more code in the kernel reachable by ordinary users.
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.
▶ No.875847>>875871
>>875814
>user namespaces still expose a lot of code in the kernel to normal users that was previously only really accessible to root
yeah, that's the key point. this should not happen IMO.
▶ No.875871>>876078
>>875847
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.
▶ No.875877>>875878 >>875880 >>876078
>>875657
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.
>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.
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.
>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?
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.
▶ No.875878
>>875877
>There is no isolation on x86 see meltdown & spectre.
Yea there is lol. You just have to store things in different address spaces. It slows things down a bit but solves the problems.
▶ No.875880>>875901
>>875877
>There is no isolation on x86, see meltdown and spector
Proper implementation of isolation on x86 is why AMD is immune to meltdown and not Intel.
▶ No.875901>>875909
>>875880
AMD is still vulnerable to Spectre which has the same effect
▶ No.875903
>>875814
>Can people prevent namespaced processes from gaining CAP_SYS_ADMIN?
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...
▶ No.875909>>875915 >>876197
>>875901
Sprectre isn't X86 specific, which is what you were implying. PPC, ARM and many other architectures also suffer from sprectre, not just AMD.
▶ No.875915
>>875909
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.
▶ No.876078
>>875871
>No, I don't agree on that point. Why are some parts of kernel OK to expose while others are not? Makes no sense.
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.
>>875877
>there is still lots of information in /proc and /sys to do all kinds of cheeky stuff
for example?
▶ No.876197
>>875909
>which is what you were implying
No. I'm implying process isolation is all fucked unless you put everything in different address spaces.
▶ No.876253>>876394 >>876423
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.
▶ No.876394>>876400 >>876536
>>876253
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.
▶ No.876396
▶ No.876400
>>876394
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.
▶ No.876423>>876471 >>876536
>>876253
>because applications can access each other in X?
you can use macOS; Cocoa doesn't have such baby problems.
▶ No.876471>>876475
▶ No.876475
>>876471
wow, how nice that you also told me.
really scared me. 10/10
▶ No.876536>>876713
>>876423
You're kidding, right?
>>876394
>The problem is the attack surface of namespaces
Is there no way to reduce the attack surface? As in >>875814:
>Can people prevent namespaced processes from gaining CAP_SYS_ADMIN?
▶ No.876713
>>876536
The only way is to disable it completely
>sysctl user.max_user_namespaces=0