Sure, but it's at least something that we can try. On Mon, Sep 17, 2018 at 1:06 PM Steve Grubb <[email protected]> wrote:
> 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 -- > > > > > -- 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]
