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 <[email protected]> wrote: > Hi Steve, > > On Mon, Nov 26, 2018 at 9:41 AM Steve Grubb <[email protected]> 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 --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
