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
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
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 --
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 --
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.fedor...
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.fedor...
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.fedor...
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.
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.fedor...
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.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
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 --
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 --
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@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
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@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@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
--
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 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.fe dorahosted.org
scap-security-guide@lists.fedorahosted.org
-
Sean -
Steve Grubb -
Trevor Vaughan