Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Tue, Jun 12, 2018 at 10:49:35AM -1000, Joel Roth wrote: > Hi Andreas, > > And thanks for the explanations! > > Andreas Messer wrote: > > Hi Joel, > > dd> > On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > > > [...] > > > I have and use dbus apps on my system, However, as far as > > > I'm aware, none of these programs has root privileges. > > > > > > As the pam/dbus/elogind/polkit mechanism is capable of > > > handing out root authority, and as all software has bugs, I > > > think we _can_ anticipate that bugs that create security holes > > > will be uncovered in this stack. How much scrutiny did the > > > developers devote? Did anyone ever consider security at > > > through the whole stack? Probably the developers of each > > > component do consider security in their own code. > > > > I'm not sure but i think there is a miss-understanding here. Neither > > dbus, elogind or polkit hand out "root" to other processes. > > > > dbus is just a rather standarized IPC mechanism to allow for > > communication between different processes. > > I may have confused ipc with rpc. > > > Also to make > > system processes (running with root permission) to talk with > > desktop applications. Of course, depending on the particular dbus > > interface the system process provides and how it implements it, > > this might become an attack vector. But in my oppinion this is > > more an issue of the system process implementation and > > dbus api interface definition of that service than of dbus it self. > > > > polkit is some kind of authority which is used by many system > > processes to figure out if a particular user or process is allowed > > to invoke a (in most cases dbus) api of a (maybe system) service. > > Wether access is granted depends on particular rules and maybe > > system state - here comes the session management into > > play. Many of the rules include a "the user must be > > running an active local session" statement. polkit does not perform > > any actions, it just veryfies that something can invoke something > > and reports the result back. > > > > polkit can be backed by two different session management systems, > > either consolekit or logind. But some desktop environments rely > > on a particular one. > > > > elogind itself is one of these session management implementations > > (providing the logind interface) and it tracks the sessions. In > > addition it does some things to the cgroups of the user processes > > and other weird things - its based on systemd-logind. > > > > In order to run without root permissions the xorg xserver > > relies on the session management. I think (not fully sure about this) > > that the session management services can also prepare > > permissions of device files, e.g. granting access to drm files > > for the x-server. > > ISTR that vdev can give process-specific views of /dev, and > appears to offer a different, lightweight option in that direction.[1] > Not clear how much these overlap, pretty clear that vdev > doesn't have anything to say about cgroups. Thanks for the info. The cgroup thing, well I have no idea if that would be really needed to run a desktop system. I was surprised by this when seen the first time. I think system-logind (and in turn elogind) use it to figure out if a process belong to a particular session. system-logind can/will also set various limits while elogind does not as far as i know. While I can understand the session management usecase, I'm not sure if the other crap is really required, especially since there are exisiting solutions for cgroup management. > [...] > So, I'm looking into the security implications of setuid X, > and found this helpful explanation on stackexchange:[2] > >X11 apps run as a non-root user. However, on most platforms >the X11 drivers run as root, so they can access the display >hardware. This introduces the risk that a malicious app >might be able to exploit some security vulnerability in the >X11 code and use it to become root. This is a serious risk, >because X11 is a complex system with a tremendous amount of >code, and all it takes is one security vulnerability >anywhere in that code to make a privilege escalation attack >possible. This is indeed a concern. > >Enabling remote attacks. If I run X11 on my Linux machine, >does that make it easy (or possible) for remote attackers to >"hack" my machine? The answer is no. Remote attackers have >no way to access or talk to X11, so running X11 on my >machine does not make my machine insecure. Fun fact about this is, having Xserver run as non-root wont protect you either. There were some kernel/xorg combinations which suffered from an anoying bug in direct rendering manager - I did not fully understood if it was the xorg driver's fault or a kernel issue. This bug made the whole graphics system crash, crash that even the tty console was not usable anymore (only ssh).
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
Hi Andreas, And thanks for the explanations! Andreas Messer wrote: > Hi Joel, > > On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > > [...] > > I have and use dbus apps on my system, However, as far as > > I'm aware, none of these programs has root privileges. > > > > As the pam/dbus/elogind/polkit mechanism is capable of > > handing out root authority, and as all software has bugs, I > > think we _can_ anticipate that bugs that create security holes > > will be uncovered in this stack. How much scrutiny did the > > developers devote? Did anyone ever consider security at > > through the whole stack? Probably the developers of each > > component do consider security in their own code. > > I'm not sure but i think there is a miss-understanding here. Neither > dbus, elogind or polkit hand out "root" to other processes. > > dbus is just a rather standarized IPC mechanism to allow for > communication between different processes. I may have confused ipc with rpc. > Also to make > system processes (running with root permission) to talk with > desktop applications. Of course, depending on the particular dbus > interface the system process provides and how it implements it, > this might become an attack vector. But in my oppinion this is > more an issue of the system process implementation and > dbus api interface definition of that service than of dbus it self. > > polkit is some kind of authority which is used by many system > processes to figure out if a particular user or process is allowed > to invoke a (in most cases dbus) api of a (maybe system) service. > Wether access is granted depends on particular rules and maybe > system state - here comes the session management into > play. Many of the rules include a "the user must be > running an active local session" statement. polkit does not perform > any actions, it just veryfies that something can invoke something > and reports the result back. > > polkit can be backed by two different session management systems, > either consolekit or logind. But some desktop environments rely > on a particular one. > > elogind itself is one of these session management implementations > (providing the logind interface) and it tracks the sessions. In > addition it does some things to the cgroups of the user processes > and other weird things - its based on systemd-logind. > > In order to run without root permissions the xorg xserver > relies on the session management. I think (not fully sure about this) > that the session management services can also prepare > permissions of device files, e.g. granting access to drm files > for the x-server. ISTR that vdev can give process-specific views of /dev, and appears to offer a different, lightweight option in that direction.[1] Not clear how much these overlap, pretty clear that vdev doesn't have anything to say about cgroups. > That why the non-setuid xserver needs elogind or > consolekit to be useable. If these are not to be used, the legacy > package with setuid wrapper is needed to run x from console So, I'm looking into the security implications of setuid X, and found this helpful explanation on stackexchange:[2] X11 apps run as a non-root user. However, on most platforms the X11 drivers run as root, so they can access the display hardware. This introduces the risk that a malicious app might be able to exploit some security vulnerability in the X11 code and use it to become root. This is a serious risk, because X11 is a complex system with a tremendous amount of code, and all it takes is one security vulnerability anywhere in that code to make a privilege escalation attack possible. This is indeed a concern. Enabling remote attacks. If I run X11 on my Linux machine, does that make it easy (or possible) for remote attackers to "hack" my machine? The answer is no. Remote attackers have no way to access or talk to X11, so running X11 on my machine does not make my machine insecure. > > Will someone who scrutinizes closer have a back door, > > is that likely be true for the foreseeable future? > > > > In a way, running others' code is like driving: putting > > oneself in the hands of strangers you've never met and > > might not trust for minute in person. > > Well, you can say this about any software you run > which you did not compile by yourself and before that, > read and understood its whole source code and all of its > dependencies and interactions. In this instance, I have heard people saying "setuid X is a security risk, we should switch over to PAM. According to this reference, it isn't such a risk. The underlying idea of PAM seems reasonable to me, however, the complexity of the stack above PAM in LOC leads me me question if my single-user system needs this. I consider myself fortunate to have the choice! greets, > cheers > Andreas 1. https://judecnelson.blogspot.com/2015/01/introducing-vdev.html 2.
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
Thank you for your reply. I should have started by RTFM (or in this case, reading the release notes). I walked away from the computer for two days and on the third day followed the documentation, behold, X ascended to F7 and played nice with screen & byobu & all of the virtual terminals. I should not have assumed that I understood it before. I'm also impressed with the boot up time. For me it is just over 10 seconds from selecting to grub entry to login prompt. The Devuan developers and the community is doing a wonderful job. And Thank You again for your patience. There is much rejoicing in the household today. 10.06.2018, 11:55, "KatolaZ" : > On Sun, Jun 10, 2018 at 11:15:18AM -0500, Peter Vachuska wrote: >> I really wish I had paid more attention to this thread and others warning >> about the changes to X before attempting to upgrade to ascii. My preferred >> way of working is out of a console running byobu and GNU screen and starting >> X only when needed. This no longer works as both screen and X use virtual >> terminals and instead of X starting on F7-F9, it is on F1; so that the >> console terminal is unusable. So after hours of frustration yesterday trying >> to get ascii working, I gave up and today reinstalled jessie only to find >> that xserver-xorg-legacy had been removed from the available packages; so I >> had the same problem. I had been using Devuan jessie for months and was very >> happy with it. (I should remember not to try to fix things that are not >> broke.) Fortunately, I had an old Debian wheezy installation which I'm now >> using. >> >> While any suggestions would be appreciated, I'm mostly just venting >> frustration. I know that my setup is atypical and console users won't >> influence the direction of X. Still > > Dear Peter, > > please have a look at the ASCII Release Notes: > > https://files.devuan.org/devuan_ascii/Release_notes.txt > > which provide an explanation of the whole X.org matter and of the > solutions available in Devuan ASCII. I understand the frustration, but > the best way to get out of it is to do something to solve the > problem. Whatever you can. > > Devuan has proven that we are all potential Devuan developers. This is > exactly what happened with elogind, just to make an example. It was > pushed into reality within a couple of months by the stubborness and > committment of a few fellow devuaner. Each of them put what they had > (knowledge, time, patience, attention to detail, etc.), and the result > is that we all can choose among more DE alternatives in Devuan ASCII. > > Devuan is really what we want it to become. > > HH > > KatolaZ > > -- > [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] > [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] > [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] > [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] > [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] > , > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
Hi Joel, On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > [...] > I have and use dbus apps on my system, However, as far as > I'm aware, none of these programs has root privileges. > > As the pam/dbus/elogind/polkit mechanism is capable of > handing out root authority, and as all software has bugs, I > think we _can_ anticipate that bugs that create security holes > will be uncovered in this stack. How much scrutiny did the > developers devote? Did anyone ever consider security at > through the whole stack? Probably the developers of each > component do consider security in their own code. I'm not sure but i think there is a miss-understanding here. Neither dbus, elogind or polkit hand out "root" to other processes. dbus is just a rather standarized IPC mechanism to allow for communication between different processes. Also to make system processes (running with root permission) to talk with desktop applications. Of course, depending on the particular dbus interface the system process provides and how it implements it, this might become an attack vector. But in my oppinion this is more an issue of the system process implementation and dbus api interface definition of that service than of dbus it self. polkit is some kind of authority which is used by many system processes to figure out if a particular user or process is allowed to invoke a (in most cases dbus) api of a (maybe system) service. Wether access is granted depends on particular rules and maybe system state - here comes the session management into play. Many of the rules include a "the user must be running an active local session" statement. polkit does not perform any actions, it just veryfies that something can invoke something and reports the result back. polkit can be backed by two different session management systems, either consolekit or logind. But some desktop environments rely on a particular one. elogind itself is one of these session management implementations (providing the logind interface) and it tracks the sessions. In addition it does some things to the cgroups of the user processes and other weird things - its based on systemd-logind. In order to run without root permissions the xorg xserver relies on the session management. I think (not fully sure about this) that the session management services can also prepare permissions of device files, e.g. granting access to drm files for the x-server. That why the non-setuid xserver needs elogind or consolekit to be useable. If these are not to be used, the legacy package with setuid wrapper is needed to run x from console > Will someone who scrutinizes closer have a back door, > is that likely be true for the foreseeable future? > > In a way, running others' code is like driving: putting > oneself in the hands of strangers you've never met and > might not trust for minute in person. Well, you can say this about any software you run which you did not compile by yourself and before that, read and understood its whole source code and all of its dependencies and interactions. cheers Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Sun, Jun 10, 2018 at 11:44:56PM +0200, k...@aspodata.se wrote: > KatolaZ: > > On Sun, Jun 10, 2018 at 11:15:18AM -0500, Peter Vachuska wrote: > ... > > > I know that my setup is atypical and console users won't > > > influence the direction of X. Still > > > Dear Peter, > > > > please have a look at the ASCII Release Notes: > > > > https://files.devuan.org/devuan_ascii/Release_notes.txt > > > > which provide an explanation of the whole X.org matter and of the > > solutions available in Devuan ASCII. > > That doesn't explain why, it just says something like: > we do like this and you can adjust to that by doing ... > So basically you exchanged suid X with suid consolekit/elogind ? > And if I don't need a session manager, I have been inconvenienced. Except we (Devuan) didn't. Debian did. > > > I understand the frustration, but > > the best way to get out of it is to do something to solve the > > problem. Whatever you can. > ... > > Can't you just do (don't have an ascii system to test on for the moment) > chmod 4711 /usr/bin/Xorg > and then just run it as you whish ? > It's not as easy as it looks to you. The main reason is the interaction with login and session managers. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
KatolaZ: > On Sun, Jun 10, 2018 at 11:15:18AM -0500, Peter Vachuska wrote: ... > > I know that my setup is atypical and console users won't > > influence the direction of X. Still > Dear Peter, > > please have a look at the ASCII Release Notes: > > https://files.devuan.org/devuan_ascii/Release_notes.txt > > which provide an explanation of the whole X.org matter and of the > solutions available in Devuan ASCII. That doesn't explain why, it just says something like: we do like this and you can adjust to that by doing ... So basically you exchanged suid X with suid consolekit/elogind ? And if I don't need a session manager, I have been inconvenienced. > I understand the frustration, but > the best way to get out of it is to do something to solve the > problem. Whatever you can. ... Can't you just do (don't have an ascii system to test on for the moment) chmod 4711 /usr/bin/Xorg and then just run it as you whish ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Sat, 9 Jun 2018 13:52:06 -1000 Joel Roth wrote: > Colleagues! > > Earlier in this thread, we learned that installing xserver-xorg-legacy > allows you to run X the old way, as a setuid script. > > The default upgrade path from jessie -- in which X11 was > setuid-only -- migrates to a new xserver-xorg in which the > setuid mechanism is replaced. In order to run X with user > permissions in the dist-upgrade'd environment one needs to > pull in a stack of dependencies including dbus, polkit, > libpam-elogind, and elogind. Hi Joel, I've noted that suggested documentation already solved your problem and the problem of the person whose X no longer opened on Ctrl+Alt+F7, so my post is just for contemplation... I don't know if the new method really runs X as a normal user, but the setuid method ran it as root, but enabled a normal user to run it. I'd imagine a line in /etc/sudoers would accomplish the same thing. I imagine that if you boot to a Display Manager like slim, xdm, lxdm and the like, this problem is already solved for you because the init runs the Display Manager as root. I'd imagine the "run as root" problem occurs only when you boot up in CLI and then run startx to go X. Again, /etc/sudoers should cover the problem. Or, perhaps, have X be a service in the init, so it can be started by root at boot (without a Display Manager). In runit the X directory can have a file named "down" so it doesn't automatically run: You could run it like: sv up X The preceding would need to be run as root, but again, /etc/sudoers. Or you could have a setuid shellscript called "togglex" that would alternate sv up X and sv down X: No /etc/sudoers, just run it. In the preceding several paragraphs, runit doesn't need to be the init: It can be run simply be a process supervisor like daemontools. I haven't tried these ideas, but I *think* they should work. SteveT Steve Litt June 2018 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
KatolaZ wrote: > please have a look at the ASCII Release Notes: > > https://files.devuan.org/devuan_ascii/Release_notes.txt > > which provide an explanation of the whole X.org matter and of the > solutions available in Devuan ASCII. Thank you (and the author) for this reference. Somehow I'd missed it. -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Sun, Jun 10, 2018 at 11:15:18AM -0500, Peter Vachuska wrote: > I really wish I had paid more attention to this thread and others warning > about the changes to X before attempting to upgrade to ascii. My preferred > way of working is out of a console running byobu and GNU screen and starting > X only when needed. This no longer works as both screen and X use virtual > terminals and instead of X starting on F7-F9, it is on F1; so that the > console terminal is unusable. So after hours of frustration yesterday trying > to get ascii working, I gave up and today reinstalled jessie only to find > that xserver-xorg-legacy had been removed from the available packages; so I > had the same problem. I had been using Devuan jessie for months and was very > happy with it. (I should remember not to try to fix things that are not > broke.) Fortunately, I had an old Debian wheezy installation which I'm now > using. > > While any suggestions would be appreciated, I'm mostly just venting > frustration. I know that my setup is atypical and console users won't > influence the direction of X. Still Dear Peter, please have a look at the ASCII Release Notes: https://files.devuan.org/devuan_ascii/Release_notes.txt which provide an explanation of the whole X.org matter and of the solutions available in Devuan ASCII. I understand the frustration, but the best way to get out of it is to do something to solve the problem. Whatever you can. Devuan has proven that we are all potential Devuan developers. This is exactly what happened with elogind, just to make an example. It was pushed into reality within a couple of months by the stubborness and committment of a few fellow devuaner. Each of them put what they had (knowledge, time, patience, attention to detail, etc.), and the result is that we all can choose among more DE alternatives in Devuan ASCII. Devuan is really what we want it to become. HH KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On 06/10/2018 12:15 PM, Peter Vachuska wrote: > I really wish I had paid more attention to this thread and others warning > about the changes to X before attempting to upgrade to ascii. My preferred > way of working is out of a console running byobu and GNU screen and starting > X only when needed. This no longer works as both screen and X use virtual > terminals and instead of X starting on F7-F9, it is on F1; so that the > console terminal is unusable. If you're working on tty1, then alt-F2, log in and run startx. ctrl-alt-F1 to get back to your console. alt-F2 again to get back to your desktop. fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
I really wish I had paid more attention to this thread and others warning about the changes to X before attempting to upgrade to ascii. My preferred way of working is out of a console running byobu and GNU screen and starting X only when needed. This no longer works as both screen and X use virtual terminals and instead of X starting on F7-F9, it is on F1; so that the console terminal is unusable. So after hours of frustration yesterday trying to get ascii working, I gave up and today reinstalled jessie only to find that xserver-xorg-legacy had been removed from the available packages; so I had the same problem. I had been using Devuan jessie for months and was very happy with it. (I should remember not to try to fix things that are not broke.) Fortunately, I had an old Debian wheezy installation which I'm now using. While any suggestions would be appreciated, I'm mostly just venting frustration. I know that my setup is atypical and console users won't influence the direction of X. Still 09.06.2018, 18:52, "Joel Roth" : > Colleagues! > > Earlier in this thread, we learned that installing xserver-xorg-legacy > allows you to run X the old way, as a setuid script. > > The default upgrade path from jessie -- in which X11 was > setuid-only -- migrates to a new xserver-xorg in which the > setuid mechanism is replaced. In order to run X with user > permissions in the dist-upgrade'd environment one needs to > pull in a stack of dependencies including dbus, polkit, > libpam-elogind, and elogind. > > I think it may be a bug that in the case of my upgrade > experience, neither xserver-xorg-legacy (a wrapper that > enables setuid X) nor this pam stack were installed, so > startx failed for me. Perhaps the experience is different > with a display manager installed. > > I have and use dbus apps on my system, However, as far as > I'm aware, none of these programs has root privileges. > > As the pam/dbus/elogind/polkit mechanism is capable of > handing out root authority, and as all software has bugs, I > think we _can_ anticipate that bugs that create security holes > will be uncovered in this stack. How much scrutiny did the > developers devote? Did anyone ever consider security at > through the whole stack? Probably the developers of each > component do consider security in their own code. > > openssl had a big hole for years, and before that debian's random > number generator was broken. Showstopping > holes, but the show goes on... > > Will someone who scrutinizes closer have a back door, > is that likely be true for the foreseeable future? > > In a way, running others' code is like driving: putting > oneself in the hands of strangers you've never met and > might not trust for minute in person. > > I read about the art of "fuzzing" programs with various > combinations of random inputs, to discover bugs such as > buffer overflows. This technique has been used to find bugs > and improve security in many languages. It was also used to > find hidden instructions and other attributes of > microprocessors. > > https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf > > I see fuzzing tools for dbus also available. > > I think it's an interesting security question, since the default > state of a distribution is so influential. > > That PAM is finely grained, I get, so on the surface, it > looks superior to the big club of root permissions. > > I'd be interested to links to any discussions of these > topics. I see the CVEs are published, in this example, > smb4k is being careless in arguments it passes to dbus, > leading to an exploit. > > https://nvd.nist.gov/vuln/detail/CVE-2017-8849 > > cheers > > -- > Joel Roth > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
