Sure, but it's at least something that we can try.
On Mon, Sep 17, 2018 at 1:06 PM Steve Grubb <sgrubb(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.fedorahosted.org
> >>> To unsubscribe send an email to
> >>> scap-security-guide-leave(a)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(a)lists.fedorahosted.org
> >> To unsubscribe send an email to
> >> scap-security-guide-leave(a)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 --