Sure, but it's at least something that we can try.

On Mon, Sep 17, 2018 at 1:06 PM Steve Grubb <sgrubb@redhat.com> 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 <tvaughan@onyxpoint.com>
>
> 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 <smalder73@gmail.com> 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 <sgrubb@redhat.com> 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 <
> >>>
> >>> tvaughan@onyxpoint.com>
> >>>
> >>> > 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 <thaller@redhat.com>
> >>>
> >>> 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 --
> >>> scap-security-guide@lists.fedorahosted.org
> >>> To unsubscribe send an email to
> >>> scap-security-guide-leave@lists.fedorahosted.org
> >>> 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 --
> >> scap-security-guide@lists.fedorahosted.org
> >> To unsubscribe send an email to
> >> scap-security-guide-leave@lists.fedorahosted.org
> >> 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.f
> >> 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 --