It seems there's a lot of people recently that don't care for security at all...
But a MAC/RBAC is supposed to block userland vectors though by checking them against system policies. Apart from possible malware in the blobs, which is not that likely but theoretically possible, the vector will always come from userland. That's why it's important to have a tight access control policy for the graphics subsystem. If you disable policies for the graphics subsystems, you're creating a huge hole in the access control system, that would allow userland vectors to exploit the bugs in the drivers or their blobs, and you're giving them a tollfree highway directly into the kernel.
I never said that I think the MAC/RBAC should protect the system against vectors in the drivers or the blobs.
It's a quite overwhelming subject these days, a lot of people just give up lol
3 Likes
Its because there's no way for us to know if nvidia is actively patching security holes because the drivers are proprietary. They also just so happen to disable major security firewalls in Linux like the people in this thread are talking about. If I had my way and the funds to do it, I'd use my 980 purely for windows and get a ryzen/skylake CPU for GPU pass through and then get an and RX 480 or something better for Linux. Then you get the best of both worlds without sacrificing your security.
edit:
offtopic but i had to say:
"That's why it's important to have a tight access control policy for the graphics subsystem"
Yep, what I was referring to which I forgot to mention regarding the "isn't very confined" comment, was that most likely (i'll have to install the proptietary drivers and check) those processes are running as some common group type (in SELinux), maybe system_t, which have a pretty broad range of access
moved all of this off-topic stuff and back and forth bs to this thread. Now everyone can continue this debate and be on topic. Derailing threads is not nice :D
2 Likes
I'm late to this, but you're asking Zoltan to create proof of what would be zero day exploits. If these exploits are known, they'd be patched. His point is that there -was- issues with the windows drivers which are ported to Linux which means those same issues would exist in Linux. Are the Linux issues fixed? Maybe. Does nvidia guarantee that their closed software is secure? Nope. If it's been compromised, or had vulnerabilities, once, it will be again.
Thanks @Alamar
Forgot to test this driver thingy.
So now that I'm back home, checking what new processes are running after installing the proprietary drivers.
~]# ps -Z aux
system_u:system_r:kernel_t:s0 root 1710 2.0 0.0 0 0 ? S 20:14 0:27 [irq/342-nvidia]
system_u:system_r:kernel_t:s0 root 1711 0.0 0.0 0 0 ? S 20:14 0:00 [nvidia]
Ok it's kernel_t type.
It's unconfined so SELinux in this case doesn't restrict it at all. Checking everything that's unconfined with:
~]# seinfo -aunconfined_domain_type -x
The nvidia binary:
/usr/bin/nvidia.* -- system_u:object_r:xserver_exec_t:s0
( xserver is also unconfined btw )
Then there's the files, surprisingly all nvidia's shared libs were actually automatically labeled with the shlib_t type, props for that I guess.
/usr/lib/nvidia*whatever -- system_u:object_r:textrel_shlib_t:s0
Ok cool, so the conclusion is both nvidia processes and xserver aren't in reality restricted by SELinux by any means.
Now onto the dilemma:
If those processes and Xorg are unconfined, how can any graphics stuff be 'very much affected by MAC/RBAC'?
This won't be beneficial for the discussion, but I was getting confused reading what @Zoltan wrote:
Does that mean, I shouldn't be using the proprietary drivers that I can select on my Xubuntu install and go for the X.org drivers instead?
That depends lol. You don't always need the security level. If you for instance have a gaming machine running proprietary drivers and steam, but you never go online with it, don't use it for work or study or bank or private data, and have two step authentication of your steam account, who cares how secure the system is.
If it's your main PC for school or work or business, better stay away from those proprietary drivers.
People are just starting to feel the effects of the miseducation from the commercial software monopoly that has existed since the nineties. Not everyone gets ransomware, not everyone's PC is turned into a spam mail server, no everyone's PC is mining bitcoin for some somalian crime syndicate. But most users are actually sitting ducks. It's like HIV in the 70' and 80's, many people died without knowing what was wrong with them, many people died because they were told that HIV was an urban myth launched by homophobic groups, in a second phase many people were positive but didn't get sick, and people started to think that it wasn't the big problem everyone was warning them for, and then there was the big wave of AIDS deaths all the way up to the early 2000's.
Many people will repeat the urban myth that you don't need tight security and privacy on your PC, because there really isn't any problem. I recommend treating any closed source software as HIV, it's better to avoid it, but if you're going to behave in a way that involves possible contact with it, make sure you wear protection. Just don't let it become a race or let it ruin the fun of computing, never believe anything, learn about stuff and make up your own informed opinion. That really is the easiest way to avoid the stress of not knowing what to do. If you understand the dangers and the pitfalls of commercial and closed source software etc because you have acquired the technical knowledge, it all become far less stressful and you can enjoy the computing experience a lot more.
3 Likes
Imo, the modules would start what they start in kernel_t because that's system default, and then a proprietary driver would always run unconfined_t by default, except that the context changes as it starts to use a subsystem tied to a different context. And that's the way everything works in SELinux. If a process isn't started at bootup in kernel_t, and isn't started in a profiled context by a system service, it will always be started in unconfined_t, because anything userland will be started in that context. If such a process then calls a service or a process for which there is a different context, that process will then inherit the context of that service or process it calls, vice versa if a service in a different context calls that process in unconfined_t, at that moment the context of that service is added. It's like a layered filtering system, an additive conditionality. So if you take a snapshot to see in what context it is running, it is only just that, a snapshot, and you have to be lucky to see it in a context except unconfined_t if it's a userland process. That's the way SELinux works in my opinion. The problem is that there are rules that allow userland processes to access certain system processes while staying in unconfined_t, and others that are forced to switch to the init_t context of the service they use. How this all relates can be seen by listing the rules of the profiles for open source applications, but exactly that is impossible for propietary drivers, there will be no such profile, there will be no rules, it will just be an open door.
I always find it funny when people argue with Zoltan..
I am not saying he is always right, it's just that he is often more right than he is ever wrong :)
I myself never assume that I'm right about anything, and I think nobody is ever right, it's the discussion that makes us all wiser, being right is not on my to do list lol
Sounds logical
So in this case there's Xserver which regardless of its context is unconfined.
Gnome processes that are system_u:system_r:xdm_t (iirc - not at the machine atm)
But when called by i.e. SELinux user_u, gnome processes inherit the user_u context, so they'd be labelled as user_u:user_r:xdm_t when they run, because there's a policy rule 'Y' stating that xdm_t indeed can inherit SELinux user contexts.
Suddenly those X sub processes are actually confined as far as the rule 'Y' actually limits them.
What about Apparmor then?
Now I don't know jack about computers but a quick look at some ootb profiles in a couple distros, it looks not-so-redundant: there's a couple policies simply stating which directories a handfull of processes can access, and if there's not a rule written then Apparmor gives the process a green light to do whatever.
How I see these are that SELinux is a whitelist while Apparmor is a blacklist.
Hardly arguing. Discussing*
The fact that hacking a Nvida gaming machine for money or for a bot net is not a mass footprint of machines in the world may be why it is overlooked for crime attacks.
On the general topic of Linux+Nvidia Securty. It pretty bad when the driver turns off SELinux and AppArmor as Zoltan stated. Just there is a stupid thing to do.
Google Project Zero found 16 bugs after looking at the Windows Driver. On the good side for Nvidia they did work fast the fix them and patched the Windows and Linux binary. So that in in Nvidia's favor.
AppArmor works a lot like SELinux, except it does not profile functional groups, it profiles individual apps. For instance, you install firefox, that cones with a profile. Most system applications ship with the corresponding profile. Open source applications that are adopted into the SuSE repo structure, are encouraged to provide profiles, meaning that the devs of those applications usually have to make their own profiles, but apparmor provides tools to make that relatively easy. However, there aren't that many profiles for userspace applications besides the main ones SuSE ships by default. In Ubuntu, apparmor has always been a bit of a mess, because as everyone knows, Canonical sees things differently...
In practice, there are no apparmor profiles for non-open-source applications. So that means no baseline MAC protection. There are however profiles of system processes that could apply as they could be called by a userland application. An exotic vector working through bugs in the nvidia driver for instance could trigger one of those, I don't know if that has actually happened or not, but it's not very probable.
There is theoretically no reason why nVidia devs couldn'r run the profiling wizard for their drivers and config utility. The problem is that there is no way to check whether or not that profile represents "safe operation", and the second problem is that there is no way to cover all grounds because the graphics driver is engaged by a lot of different processes in a lot of different scenarios, for instance on different DE's with different display managers with different compositors with different OpenGL backends with different renderers... I think nVidia would just pass on that completely or make a pro forma profile that allows pretty much everything, just because they wouldn't want to risk triggering AppArmor in the many different system constellations they couldn't test for themselves. On open source applications, the community tests, the manpower of communities is there exactly for that. In a closed source environment, where a company doesn't document what exactly goes on with their software, the company would never provide documentation in order to allow extensive profile testing in different constellations by a community. So there again, by lack of profile or certainly back lack of a restrictive profile that would actually increase security, you're left with userland hooks that can tap right into undocumented kernel modules without anything stopping them. It will be very difficult to stop for instance an escalation of privs that is executed through a kernel process which is exploited by a userland vector, and all of this happens in an undocumented, unprofiled enclave in the system. The biggest problem here - just like with SELinux - is that when you install proprietary nVidia drivers, your system's baseline AppArmor protection is weakened because those blob have to get modprobed, and after they are, you basically have a situation whereby closed source userland processes are exempt from AppArmor protection and directly tap into closed source kernel processes.
There is some residual protection, it's not all black and white, there are other linux security mechanisms like YamaLSM, which is an evolution of some GR.SEC features with regards to a.o. ptrace restrictions, whereby profiling for specific applications allows a "child only" restriction for ptrace to be implemented in non-static environments of desktop machines (GR.SEC imposes strict child only ptrace restrictions, but GR.SEC hardening only really makes sense in pretty static systems like servers, on a desktop, there is more functional entropy and that often makes full GR.SEC hardening a bit of a drag). Here for instance, Yama might block a process from using ptrace to get for instance authentication credentials from another process, if such a thing would be attempted by using the unprofiled nVidia processes. That's actually a probable hypothesis, something that is easily imaginable. The problem is that this protection would be "heuristic" at best, by lack of documentation and profiling of proprietary nVidia drivers and blobs. And it's of course only active in a limited scope.
1 Like
Given that SElinux is a NSA backdoor of which no serious linux administrator would ever enable, discussing how nvidia shared libraries somehow changes the security context is kinda moot.
1 Like
Point where those backdoors are plox, cause I can't code.
On second thought can't really trust Torvalds either, he's most likely implementing backdoors for the Finnish authorities...
Better find a trustworthy Norwegian replacement for everything.
3 Likes