Heh, turns out that I have a YES rule in place to disable the shutdown button.
Well, it does seem like the SSG should have *something* about this and at least cover the perils of running pkexec and that there should be something that at least does a cursory glance at the polkit rules. If we're not going to look at anything and are going to fall back on 'the admin knows what they are doing', then I also don't see the need to fail on NOPASSWD in sudoers. I mean, if you're running in a key-only environment, you're probably going to have NOPASSWD in your sudoers and you "know what you are doing". Trevor On Mon, Sep 17, 2018 at 3:29 PM Steve Grubb <[email protected]> wrote: > On Monday, September 17, 2018 1:30:45 PM EDT Trevor Vaughan wrote: > > Sure, but it's at least something that we can try. > > If you're scanning for polkit.Result.YES and you found it, then you got > the > ones that are shipped by default. If someone is being tricky, then you > won't > catch it with a regex. > > So, how do you feel about actions with: > > <allow_active>yes</allow_active> > > or > > <allow_any>yes</allow_any> > > These bypass authentication, too. In some cases its benign (who cares if > you > can list tuned profiles?)...in other cases it might be trouble. > > How about the _KEEP replies? The ones with auth_self? > > -Steve > > > 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]
