8:18 a.m.
Hi All,
In my never ending quest to find new and annoying ways to do everything, I
figured that I'd throw out the new list of fun.
1. Using pkexec makes sudo relatively pointless. Sure, it logs things, but
we now effectively have two sudo subsystems and one can't really have the
rules audited per my last discussion with Steve because JavaScript as a
configuration language is amazing. Not sure what to do about this one but
people should really be watching for it and I don't see any mention of it
in the rules anywhere.
2. Systemd timers can be run in user mode and effectively make all the
restrictions around cron and at pointless from what I can tell. So far, I
can't figure out how to disable user space timers or 'systemctl --user'
calls without completely removing 'pam_systemd' from the stack. No idea
what this would break but it's probably the only solution right now (or
maybe having a group-based jump stack in PAM).
3. There should probably be some sort of check to make sure that
'enable-linger' has not been set for users.
In summary, the SSG simply does not cover any of the new EL7+ capabilities
very well, particularly those that replace traditional services that are
already expected to be controlled. As systemd becomes more of an operating
system and less of service manager, this will only get worse.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
8:41 a.m.
Hello,
On Monday, November 26, 2018 9:18:07 AM EST Trevor Vaughan wrote:
In my never ending quest to find new and annoying ways to do
everything, I
figured that I'd throw out the new list of fun.
1. Using pkexec makes sudo relatively pointless. Sure, it logs things,
It does not send audit events which is a big deal.
but we now effectively have two sudo subsystems and one can't
really have
the rules audited per my last discussion with Steve because JavaScript as a
configuration language is amazing. Not sure what to do about this one but
people should really be watching for it and I don't see any mention of it
in the rules anywhere.
What I told the Fedora community is that the only thing that can be done is
to get a SHA256 hash of the auth file and compare that during security audits.
Its suboptimal but should work.
2. Systemd timers can be run in user mode and effectively make all
the
restrictions around cron and at pointless from what I can tell.
Cron and at can do auditing and MLS. Which is a big deal for security.
Systemd has no auditing for timers nor can it do MLS. One thing to know about
systemd is that they place a lot of functionality in it for minimal systems.
For example if you are designing an embedded system, then systemd's
functionality may be good enough such that you do not need to drag in lots of
dependencies which increase the footprint. However, it is not a replacement
for full fledged security solutions. For example, systemd can replace xinetd.
However, it cannot do MLS nor any of the fancy blocking that xinetd can do.
So far, I
can't figure out how to disable user space timers or 'systemctl --user'
calls without completely removing 'pam_systemd' from the stack. No idea
what this would break but it's probably the only solution right now (or
maybe having a group-based jump stack in PAM).
If it cannot be disabled, then it must be auditable. I'd say a bz may need to
be opened on this.
-Steve
3. There should probably be some sort of check to make sure that
'enable-linger' has not been set for users.
In summary, the SSG simply does not cover any of the new EL7+ capabilities
very well, particularly those that replace traditional services that are
already expected to be controlled. As systemd becomes more of an operating
system and less of service manager, this will only get worse.
Thanks,
Trevor
9:03 a.m.
Hi Steve,
On Mon, Nov 26, 2018 at 9:41 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
On Monday, November 26, 2018 9:18:07 AM EST Trevor Vaughan wrote:
> In my never ending quest to find new and annoying ways to do everything,
I
> figured that I'd throw out the new list of fun.
>
> 1. Using pkexec makes sudo relatively pointless. Sure, it logs things,
It does not send audit events which is a big deal.
I had no idea about this. That's super fun. It logs to syslog but having it
jump the audit chain is fun.
> but we now effectively have two sudo subsystems and one
can't really have
> the rules audited per my last discussion with Steve because JavaScript
as a
> configuration language is amazing. Not sure what to do about this one but
> people should really be watching for it and I don't see any mention of it
> in the rules anywhere.
What I told the Fedora community is that the only thing that can be done
is
to get a SHA256 hash of the auth file and compare that during security
audits.
Its suboptimal but should work.
Unfortunately, it only works if you never add or modify anything else in
that space. That means RPMs or anything else are going to have to be really
carefully audited and, since it's JavaScript, you can literally embed
obfuscated stuff somewhere else on the OS and call it a day. Super exciting.
Currently, I'm going with a puppet based authoritative management and purge
but I'm not sure how you make that generic.
> 2. Systemd timers can be run in user mode and effectively make all the
> restrictions around cron and at pointless from what I can tell.
Cron and at can do auditing and MLS. Which is a big deal for security.
Systemd has no auditing for timers nor can it do MLS. One thing to know
about
systemd is that they place a lot of functionality in it for minimal
systems.
For example if you are designing an embedded system, then systemd's
functionality may be good enough such that you do not need to drag in lots
of
dependencies which increase the footprint. However, it is not a
replacement
for full fledged security solutions. For example, systemd can replace
xinetd.
However, it cannot do MLS nor any of the fancy blocking that xinetd can do.
So, it sounds like systemd needs to be updated with MLS/SELinux support or
it needs to be able to run in "this isn't a minimial system so stop trying
to be helpful" mode. In the mean time, shouldn't the SSG have rules to
disable all of the shenanigans that replace better OS services.
Unfortunately, I think that you may be one of the few people that can
actually enumerate these without a bunch of dumpster diving.
> So far, I
> can't figure out how to disable user space timers or 'systemctl --user'
> calls without completely removing 'pam_systemd' from the stack. No idea
> what this would break but it's probably the only solution right now (or
> maybe having a group-based jump stack in PAM).
If it cannot be disabled, then it must be auditable. I'd say a bz may need
to
be opened on this.
Well, is there a problem with jumping over `pam_systemd` except for
specific users? I simply don't know what this would break. If that works,
then we can add that to the SSG. If not, yeah, that could be a problem.
-Steve
> 3. There should probably be some sort of check to make sure that
> 'enable-linger' has not been set for users.
I did a quick dig on this one and it looks like auditing
/var/lib/systemd/linger for files should work fine and should be simple to
implement.
>
> In summary, the SSG simply does not cover any of the new EL7+
capabilities
> very well, particularly those that replace traditional services that are
> already expected to be controlled. As systemd becomes more of an
operating
> system and less of service manager, this will only get worse.
>
> Thanks,
>
> Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
1:13 p.m.
On a related note to pkexec, anyone know how to mitigate this?
https://thehackernews.com/2018/12/linux-user-privilege-policykit.html
Thanks,
Trevor
On Mon, Nov 26, 2018 at 10:03 AM Trevor Vaughan <tvaughan(a)onyxpoint.com>
wrote:
Hi Steve,
On Mon, Nov 26, 2018 at 9:41 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
> Hello,
>
> On Monday, November 26, 2018 9:18:07 AM EST Trevor Vaughan wrote:
> > In my never ending quest to find new and annoying ways to do
> everything, I
> > figured that I'd throw out the new list of fun.
> >
> > 1. Using pkexec makes sudo relatively pointless. Sure, it logs things,
>
> It does not send audit events which is a big deal.
>
I had no idea about this. That's super fun. It logs to syslog but having
it jump the audit chain is fun.
> > but we now effectively have two sudo subsystems and one can't really
> have
> > the rules audited per my last discussion with Steve because JavaScript
> as a
> > configuration language is amazing. Not sure what to do about this one
> but
> > people should really be watching for it and I don't see any mention of
> it
> > in the rules anywhere.
>
> What I told the Fedora community is that the only thing that can be done
> is
> to get a SHA256 hash of the auth file and compare that during security
> audits.
> Its suboptimal but should work.
>
Unfortunately, it only works if you never add or modify anything else in
that space. That means RPMs or anything else are going to have to be really
carefully audited and, since it's JavaScript, you can literally embed
obfuscated stuff somewhere else on the OS and call it a day. Super exciting.
Currently, I'm going with a puppet based authoritative management and
purge but I'm not sure how you make that generic.
>
>
> > 2. Systemd timers can be run in user mode and effectively make all the
> > restrictions around cron and at pointless from what I can tell.
>
> Cron and at can do auditing and MLS. Which is a big deal for security.
> Systemd has no auditing for timers nor can it do MLS. One thing to know
> about
> systemd is that they place a lot of functionality in it for minimal
> systems.
> For example if you are designing an embedded system, then systemd's
> functionality may be good enough such that you do not need to drag in
> lots of
> dependencies which increase the footprint. However, it is not a
> replacement
> for full fledged security solutions. For example, systemd can replace
> xinetd.
> However, it cannot do MLS nor any of the fancy blocking that xinetd can
> do.
>
So, it sounds like systemd needs to be updated with MLS/SELinux support or
it needs to be able to run in "this isn't a minimial system so stop trying
to be helpful" mode. In the mean time, shouldn't the SSG have rules to
disable all of the shenanigans that replace better OS services.
Unfortunately, I think that you may be one of the few people that can
actually enumerate these without a bunch of dumpster diving.
>
> > So far, I
> > can't figure out how to disable user space timers or 'systemctl
--user'
> > calls without completely removing 'pam_systemd' from the stack. No idea
> > what this would break but it's probably the only solution right now (or
> > maybe having a group-based jump stack in PAM).
>
> If it cannot be disabled, then it must be auditable. I'd say a bz may
> need to
> be opened on this.
>
Well, is there a problem with jumping over `pam_systemd` except for
specific users? I simply don't know what this would break. If that works,
then we can add that to the SSG. If not, yeah, that could be a problem.
>
> -Steve
>
> > 3. There should probably be some sort of check to make sure that
> > 'enable-linger' has not been set for users.
>
I did a quick dig on this one and it looks like auditing
/var/lib/systemd/linger for files should work fine and should be simple to
implement.
> >
> > In summary, the SSG simply does not cover any of the new EL7+
> capabilities
> > very well, particularly those that replace traditional services that are
> > already expected to be controlled. As systemd becomes more of an
> operating
> > system and less of service manager, this will only get worse.
> >
> > Thanks,
> >
> > Trevor
>
>
>
>
>
--
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 --
1:18 p.m.
On 12/6/18 2:13 PM, Trevor Vaughan wrote:
On a related note to pkexec, anyone know how to mitigate this?
https://thehackernews.com/2018/12/linux-user-privilege-policykit.html
https://access.redhat.com/security/cve/cve-2018-19788
"Do not allow negative UIDs or UIDs greater than 2147483646."
....... which is weird, since patches were upstream:
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/fbaab32cb4ed9ed5f1e3...
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/7c8c3abdedbb991a69bc...
I'll ask around on the RHEL product security team to see what's up.
1:20 p.m.
On 12/6/18 2:18 PM, Shawn Wells wrote:
On 12/6/18 2:13 PM, Trevor Vaughan wrote:
> On a related note to pkexec, anyone know how to mitigate this?
>
> https://thehackernews.com/2018/12/linux-user-privilege-policykit.html
>
https://access.redhat.com/security/cve/cve-2018-19788
"Do not allow negative UIDs or UIDs greater than 2147483646."
....... which is weird, since patches were upstream:
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/fbaab32cb4ed9ed5f1e3...
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/7c8c3abdedbb991a69bc...
I'll ask around on the RHEL product security team to see what's up.
If anyone wants to follow along:
https://bugzilla.redhat.com/show_bug.cgi?id=1655925
1:22 p.m.
On 12/6/18 2:20 PM, Shawn Wells wrote:
On 12/6/18 2:18 PM, Shawn Wells wrote:
>
>
>
> On 12/6/18 2:13 PM, Trevor Vaughan wrote:
>> On a related note to pkexec, anyone know how to mitigate this?
>>
>> https://thehackernews.com/2018/12/linux-user-privilege-policykit.html
>>
> https://access.redhat.com/security/cve/cve-2018-19788
>
> "Do not allow negative UIDs or UIDs greater than 2147483646."
>
> ....... which is weird, since patches were upstream:
> -
>
https://gitlab.freedesktop.org/zbyszek/polkit/commit/fbaab32cb4ed9ed5f1e3...
> -
>
https://gitlab.freedesktop.org/zbyszek/polkit/commit/7c8c3abdedbb991a69bc...
>
> I'll ask around on the RHEL product security team to see what's up.
If anyone wants to follow along:
https://bugzilla.redhat.com/show_bug.cgi?id=1655925
update: RHEL7 patch currently going through QA and should be released
shortly.
3:08 p.m.
Shawn,
While this fixes the symptom, I think that this is actually a systemd bug
as well. Libvirt handles incorrect UID entries correctly.
https://bugzilla.redhat.com/show_bug.cgi?id=1657021
The error handling in the authorization stack probably needs to be analyzed.
On Thu, Dec 6, 2018 at 2:23 PM Shawn Wells <shawn(a)redhat.com> wrote:
On 12/6/18 2:20 PM, Shawn Wells wrote:
On 12/6/18 2:18 PM, Shawn Wells wrote:
On 12/6/18 2:13 PM, Trevor Vaughan wrote:
On a related note to pkexec, anyone know how to mitigate this?
https://thehackernews.com/2018/12/linux-user-privilege-policykit.html
https://access.redhat.com/security/cve/cve-2018-19788
"Do not allow negative UIDs or UIDs greater than 2147483646."
....... which is weird, since patches were upstream:
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/fbaab32cb4ed9ed5f1e3...
-
https://gitlab.freedesktop.org/zbyszek/polkit/commit/7c8c3abdedbb991a69bc...
I'll ask around on the RHEL product security team to see what's up.
If anyone wants to follow along:
https://bugzilla.redhat.com/show_bug.cgi?id=1655925
update: RHEL7 patch currently going through QA and should be released
shortly.
_______________________________________________
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.fe...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
1977
days inactive
1987
days old
scap-security-guide@lists.fedorahosted.org
7 comments
3 participants
participants (3)
-
Shawn Wells -
Steve Grubb -
Trevor Vaughan