Hello Sean, On Monday, September 17, 2018 11:23:29 AM EDT Sean 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.
Right. I agree. However, you can modify your pam stack to allow root escalation without a password, too. You just don't do it. I think that its important to define the expected rules. But what I was saying is that the language is so rich that you cannot try to parse it and reason whether it is good or not. I had this same discussion way back when polkit was introduced to Fedora back in Nov 2012: https://marc.info/?l=fedora-devel-list&m=135273468717951&w=2 I tried to get some changes in place back then but not enough people understood that auditing the security posture is a must. In any event, I think the path forward is to look for the polkit enabled software that is on a server install, audit the code, if there is no code - write it. Then we can get the paths and hashs and create tests. -Steve > 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/[email protected] > > dorahosted.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]
