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 <sgrubb(a)redhat.com> 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 <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 --