Where I work things go 6 months (or more without being updated). So it would be safe to assume that fixed bugs are still issues in production environments.
4 Likes
That's your company's fault if there's disclosure tbh
The massive juniper hacks, heartbleed, cloudflare overflow, wordpress etc were a problem because of a lack of disclosure
The only thing you're asking for is trouble mr tkoham
You won't read other people's posts, and insult their intelligence, where they are trying to explain evident things to you. Read posts and think before posting anything mr tkoham
CVE stands for "common vulnerabilities and exposure" mr tkoham, that says it all
1 Like
Question:
Are OpenSSL and MongoDB open source?
off topic mr tkoham... stop being such a pain
2 Likes
Listen alright?
I don't keep my front door open until something bad happens so that i decide to keep it locked. The same goes for my windows, car doors etc..
I don't use simple passwords and wait till i get hacked so that i improve my security.
As such i don't wait until others get hacked so that i start worrying about my own security.
security bug fixes were potential data breach vectors that got fixed. We only got to know about these 'cause nvidia decided to divulge them. how many are still to be fixed who knows. they (nvidia) certainly don't have the manpower to check/fix at an acceptable level nor are they interested in it. Until they allow others to audit their code, it cannot be considered trustworthy...same goes for almost everything else from software to politics.
Oh and, hackers certainly don't go around exposing their methods. It's in their best interest not to divulge the way they breach security.
1 Like
I think it is on topic.
nvidia's evil proprietary driver: 0 reported public data breaches
Several Common OSS in production on the other hand...
Don't say it's irresponsible if there's no real world problems
Guys, dont you think you've flirted enough here? I'm starting to get jealous.
Maybe since this is such a debatable topic it would be in the interest of users (like me) who are less knowledgeable to start a new thread about it. OP is probably not benefiting from this.
2 Likes
We're used to showing nice pictures to the blind because they might regain sight over here, that's the spirit of open source and all, and we invest time in that because it is important that people should come in contact with people who share these pictures even when they are not on a specific nice picture site but are just looking to consume porn, if you know what I mean. That is why we are here. We are not impressed by a certain degree of abuse, because we're not into taking advantage of the signs of weakness someone might be showing, but abuse plus the stubborn refusal to accept facts and rational explanations, is a bridge too far.
3 Likes
I've not denied any facts. I'm just pointing out that it's hypocritical (and impractical) to have a security rationale based solely on how your software is licensed.
The moment the nvidia driver causes an issue on the scale of one of a litany of "secure" OSS, I'll shut up.
Also, that's the most tortured analogy I've seen in a while. Congrats
Lol, no you were not. You're gesticulating wildly in search of a hook to stop your fall off the cliff.
2 Likes
lmao I'm just having fun, you made your point though, I'll quit it.
@Zoltan again with the cliches, oy vey.
you still haven't found me a production breach
You are trying desperately to set him up to an unachievable task. He can't find anything on a closed source. It's not in the best interests of the owners of the code to divulge such an occurrence and hackers don't and wont reveal their methods. A situation where it could have happened is unlikely to come out!
far more likely is that it hasn't happened at any significant scale. (if at all)
Security researchers would be all over it if it had. They might not be OSS friendly, but they aren't Oracle, either, and even oracle stuff gets coverage. Also, if they fail to disclose and word gets out, they're looking at huge liability. Litigious, actionable liability.
This claim that Nvidia drivers disable MAC/RBAC is interesting - I just checked the status of apparmor and it looks like its working. Am I checking this wrong? Just running apparmor_status.
It doesn't.
I'm assuming the point is that it's impossible to have restrictive policies that affect the drivers' procs and libs, which in practice mean those won't be affected by any MAC/RBAC.
The way Apparmor works is you have a defined set of applications that can access specific directories, everything else it turns a blind eye to. (Normally just a couple net-facing processes)
SELinux is the same with a couple extra features unless you have it running with an MLS policy/remove an 'allow all the rest' rule (since SELinux blocks everything by default).
But if you're enabling MLS/actually blocking everything except what's specifically allowed, your machine is prolly a military drone and doesn't need X anyway lol.
Summa summarum graphics stuff ain't affected by MAC/RBAC anyway so it's a null statement.
Unless I'm totally out in the wind. Enlighten me if I am.
1 Like
Nope, that's pretty much the long and short of it in practical terms.
Nope, you're really wrong on that, there are several problems. First of all of course is that the driver modprobes uncheckable crap. That is just about the largest security threat imaginable on any system. There is absolutely no control whatsoever over what is modprobed into the kernel with every driver update when using nvidia/fglrx. All that is known, and that is a fact, is that there are "special drivers" provided that work on systems with selinux, whereas the normal drivers from nvidia itself don't. The modprobing is also why selinux must be disabled in order to install nvidia or fglrx proprietary drivers.
Second problem is that some critical processes, notably virtualisation (one of the main tools in increasing security), have to be used with selinux disabled (which then pretty much annuls the whole point of the exercise) in order to work with proprietary drivers.
There is no functional isolation any more on modern systems, a restrictive RBAC is an absolute necessity, especially when using virtual GPU technology and other modern functionality.
Setting SELinux to permissive or making a general exception to apparmor is extremely dangerous. Graphics stuff is very much affected by MAC/RBAC.
The reason why AMD went for a userland approach with AMDGPU PRO, is to avoid exactly all of this. Why would they even have gone through all of the trouble if it's a "null statement"?
Read the documentation of the link provided by Rugaliz above, you'll see that your "graphics stuff that isn't affected by your RBAC anyway", leads to escalation of privs, data leakage and unauthorized access on the system... that's why SELinux and AppArmor should never be disabled, that's exactly the kind of security safety net provided by MAC/RBAC systems. That documentation comes from nVidia itself, and every single entry, about a dozen just for that CVE, and there are plenty of CVE's on nVidia drivers, talks about escalation of privs and unauthorized access, so is right in the core application radius of MAC/RBAC systems. If you disable those systems for everything concerning the graphics (and compute acceleration and shared memory management and shared memory access and virtualization etc because those are also core driver functions of the GPU unit), you have a dangerously exposed system that can't benefit fron the one system that's explicitly put there to prevent prejudice from bugs like that.
5 Likes
Ofc it's a security issue, anything running down in kernel space isn't affected by MAC/RBAC tho since those are userland only security features, no?
That's the problem with proprietary blobs, MAC/RBAC means jack down on kernel level, and a compromized kernel is game over.
Nvidias drivers downloaded from their website does indeed install no problem at least on Fedora with SELinux enforcing running Fedora's targeted policy.
But there still are some userland stuff going on, with proprietary drivers, which are blocked by SELinux but everything is perfectly usable with SELinux enforcing.
Virtualization and containers also work fine with Nvidias proprietary drivers. Now some instances SELinux indeed does block, like systemd-nspawn for example but those aren't related to proprietary drivers.
Virtual GPU stuff idk if it's worth talking about here since it works with intel only anyway (>broadwell gen).
So MAC/RBAC doesn't need to be disabled, but the kernel is compromized anyway.