[HN Gopher] SELinux bypasses
       ___________________________________________________________________
        
       SELinux bypasses
        
       Author : voxadam
       Score  : 87 points
       Date   : 2024-10-25 15:53 UTC (7 hours ago)
        
 (HTM) web link (klecko.github.io)
 (TXT) w3m dump (klecko.github.io)
        
       | rwmj wrote:
       | I'm a bit confused by this article. If you have a way to write
       | arbitrarily into kernel structures can't you pretty much do
       | anything already?
        
         | DougMerritt wrote:
         | On raw hardware, yes, but they're talking about running on a
         | Samsung hypervisor.
        
       | wannacboatmovie wrote:
       | The problem with SELinux is it's very fragile and basically
       | broken outside RedHat distros.
       | 
       | As an experiment I installed SELinux on Debian and while I was
       | eventually able to get it stable and working after a lot of trial
       | and error, a disk swap followed by an rsync broke it irreparably.
       | Yes I rescanned the disk or whatever to have SEL relearn/reindex
       | the objects, didn't work. The box was basically unbootable or it
       | would boot and rejected all logins, including root directly to
       | the console, something that should nearly never happen.
       | Documentation is sparse or assumes you have RedHat and it 'just
       | works'. After hours of troubleshooting the only thing that worked
       | was switching it off and saying good riddance.
        
         | totony wrote:
         | Most distros use https://github.com/SELinuxProject/refpolicy
         | while RHEL uses https://github.com/fedora-selinux/selinux-
         | policy
         | 
         | It's also my experience that Fedora has better support for it,
         | but Gentoo used to be good enough with hardened gentoo (they
         | use https://gitweb.gentoo.org/proj/hardened-refpolicy.git/).
         | Redhat and Gentoo are the only ones that officially support it
         | afaik. I think hardened gentoo might have lost popularity since
         | the fall of grsec, but I'm not sure how popular it is
         | currently.
        
           | vlovich123 wrote:
           | FWIW Android also uses SELinux & I believe selinux-policy.
           | Have no idea about the quality of the implementation.
        
             | BSDobelix wrote:
             | >Android also uses SELinux
             | 
             | Too bad you haven't even read a part of the article.
        
         | kbolino wrote:
         | Gentoo added some excellent and fairly distro-neutral
         | documentation for SELinux a few years ago which makes it
         | somewhat viable outside of Red Hat. It's also helpful for
         | debugging issues even on Red Hat.
         | 
         | https://wiki.gentoo.org/wiki/SELinux
        
       | Animats wrote:
       | SELinux for Linux was never intended to be highly secure. When
       | NSA created it [1], the intent was to get user software modified
       | to work in a mandatory access control environment. Then, more
       | secure operating systems for DoD use would be able to run
       | available software.
       | 
       | NSA used to do a lot of operating systems work, but no longer
       | seems to do that.
       | 
       | [1] https://www.nsa.gov/Research/NSA-Mission-Oriented-
       | Research/L...
        
         | transpute wrote:
         | MAC for Zephyr was presented at Linux Security Summit (2019),
         | https://www.youtube.com/watch?v=AKWFbxbsU3o                 ..
         | a flexible MAC architecture was created and matured through a
         | series of research systems. The work to bring this architecture
         | to mainstream systems [and] experience with applying this
         | architecture to mobile platforms is examined. The role of MAC
         | in a larger system architecture is reviewed in the context of a
         | secure virtualization system. The state of MAC in mainstream
         | systems is compared before and after our work.
         | 
         | Review of non-public STM for constraining SMM,
         | https://www.platformsecuritysummit.com/2018/speaker/myers/
         | We describe our work to demonstrate an enhanced SMI transfer
         | monitor (STM) to provide protected execution services on the
         | x86 platform. An STM is a hypervisor that executes in x86
         | system management mode (SMM) and functions as a peer to the
         | hypervisor or operating system. The STM constrains the SMI
         | handler, by hosting the handler in a virtual machine (VM).
         | Otherwise, the SMI handler holds unconstrained access to the
         | platform, which could undermine the assurance provided by DRTM
         | or TXT.
         | 
         | OSS STM contributed to coreboot, https://cyberscoop.com/nsa-
         | firmware-open-source-coreboot-stm... &
         | https://www.osfc.io/2019/talks/implementing-stm-support-for-...
         | Implementation of SMI transfer monitor (STM) support for
         | Coreboot.
        
       | chasil wrote:
       | It seems to me that every new rhel release has more switches to
       | throw to get my things installed and working.
       | 
       | It's especially a bit extreme when systemd gets the syslog
       | denial.
       | 
       | How do we dial this back?
        
         | wmf wrote:
         | Learn RHEL properly or use a different distro. RHEL isn't going
         | to change its philosophy.
        
           | ruthmarx wrote:
           | You are being downvoted but this answer is exactly right.
           | It's kind of like complaining about group policy in Windows.
        
       | gnuser wrote:
       | GRSec is better imho but I've never convinced anybody to put it
       | in prod so meh
        
         | voxadam wrote:
         | I've never used Grsecurity but I seem to remember that the devs
         | didn't play too well with mainline kernel devs.[0]
         | 
         | [0] https://lwn.net/Articles/721848/
        
       ___________________________________________________________________
       (page generated 2024-10-25 23:00 UTC)