On Monday, September 17, 2018 11:48:36 AM EDT Trevor Vaughan wrote: > Ok, it looks like we want to fail on anything in /etc/polkit-1 that > contains 'return polkit.Result.YES' and that would be the equivalent of > checking for NOPASSWD in sudo.
But you can pass so many ways: return "yes"; return 'y' + 'e' + 's'; tmp = "yes"; return tmp; etc. But you can also modify rules that restrict actions to local, redefine admin groups, call out to programs, etc. -Steve > Now, I don't know how to handle cases where things are loaded from > somewhere else. > > Does anyone know how to print all active policykit rules with content? > > Thanks, > > Trevor > > On Mon, Sep 17, 2018 at 11:33 AM Trevor Vaughan <[email protected]> > > wrote: > > Yes, spirit of the rule is exactly what I am saying. > > > > In old polkit this was pretty easy (INI-style). In new polkit, I can do > > Javascript-fu and make whatever mess I'd like to make. > > > > Basically, industry caused a validation issue and I was a bit surprised > > since I thought we all agreed that configuration files that were > > executable languages were a bad idea back in the late 90's. > > > > But, that doesn't fix the issue that we have to write rules about this if > > it's going to be an enabled capability. You have to be root to edit > > /etc/sudoers as well. So, either we should cover both, or ignore both > > since they're essentially the same capability. > > > > Trevor > > > > On Mon, Sep 17, 2018 at 11:23 AM Sean <[email protected]> wrote: > >> I think the gist of what Trevor's driving at is the "Spirit of the Rule" > >> which requires privilege escalation to pass an authentication challenge. > >> He is using 'password' but the challenge could be satisfied by a number > >> of > >> methods - pkcs#11 token, ssh-key, etc. > >> > >> With sudo, NOPASSWD rules are not compliant. Polkit, if it is a gateway > >> for privilege escalation, should follow the spirit of this rule, for the > >> same reasons it exists for sudo. > >> > >> --Sean > >> > >> On Mon, Sep 17, 2018 at 11:07 AM Steve Grubb <[email protected]> wrote: > >>> On Monday, September 17, 2018 10:50:28 AM EDT Trevor Vaughan wrote: > >>> > Just tinkering around: > >>> > > >>> > If you have /etc/polkit/rules.d/10-nopasswd_hack.rules with the > >>> > >>> following > >>> > >>> > content: > >>> > > >>> > polkit.addRule(function(action, subject) { > >>> > > >>> > if (action.id == "org.freedesktop.policykit.exec" && > >>> > > >>> > subject.isInGroup("wheel")) > >>> > > >>> > { > >>> > > >>> > return polkit.Result.YES; > >>> > > >>> > } > >>> > > >>> > }); > >>> > > >>> > Then you can run the following to get a root shell with absolutely no > >>> > password prompt. > >>> > > >>> > pkexec -u root /bin/bash > >>> > >>> Yes. But you need root to put it there. My thoughts on polkit rules is > >>> that > >>> about all you can do is sha256 hash the files. The language is so > >>> complex > >>> that parsing it is impossible. You can say what should exist and what > >>> its > >>> hash should be. It goes downhill from there. > >>> > >>> -Steve > >>> > >>> > On Mon, Sep 17, 2018 at 10:19 AM Trevor Vaughan < > >>> > >>> [email protected]> > >>> > >>> > wrote: > >>> > > On a default installation? They can't but I think they can twiddle > >>> > >>> things > >>> > >>> > > in NetworkManager from the GUI IIRC. > >>> > > > >>> > > But they also can't get to root via 'sudo' and we have rules for > >>> > >>> that. > >>> > >>> > > Polkit is basically sudo for DBus stuff and we have rules around > >>> > > what > >>> > > should, and should not, be done with sudo so I guess I expect the > >>> > >>> same > >>> > >>> > > thing with polkit. > >>> > > > >>> > > For instance, I could use pkexec to run arbitrary commands as root > >>> > > without > >>> > > a password if I have a rule set up for it. But, unlike sudo, there > >>> > >>> isn't > >>> > >>> > > a > >>> > > rule saying not to do that and a method to check for it. > >>> > > > >>> > > Thanks, > >>> > > > >>> > > Trevor > >>> > > > >>> > > On Mon, Sep 17, 2018 at 9:45 AM Thomas Haller <[email protected]> > >>> > >>> wrote: > >>> > >> On Mon, 2018-09-17 at 09:19 -0400, Trevor Vaughan wrote: > >>> > >> > Otherwise, there's a > >>> > >> > lovely gaping hole in the system security that can effectively > >>> > >> > be > >>> > >> > used to run pretty much anything with root permissions. > >>> > >> > >>> > >> Hi, > >>> > >> > >>> > >> This makes me wonder. How can an unpriviledged user get root > >>> > >> permissions on a default installation of RHEL? Either in general, > >>> > >> or > >>> > >> specifically using NetworkManager. > >>> > >> > >>> > >> > >>> > >> best, > >>> > >> Thomas > >>> > > > >>> > > -- > >>> > > Trevor Vaughan > >>> > > Vice President, Onyx Point, Inc > >>> > > (410) 541-6699 x788 > >>> > > > >>> > > -- This account not approved for unencrypted proprietary > >>> > > information > >>> > >>> -- > >>> > >>> > >>> > >>> _______________________________________________ > >>> scap-security-guide mailing list -- > >>> [email protected] > >>> To unsubscribe send an email to > >>> [email protected] > >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >>> List Archives: > >>> https://lists.fedorahosted.org/archives/list/scap-security-guide@lists. > >>> fedorahosted.org>> > >> _______________________________________________ > >> scap-security-guide mailing list -- > >> [email protected] > >> To unsubscribe send an email to > >> [email protected] > >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedorahosted.org/archives/list/[email protected] > >> edorahosted.org> > > -- > > Trevor Vaughan > > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > > -- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
