[HN Gopher] SELinux bypasses
___________________________________________________________________
SELinux bypasses
Author : voxadam
Score : 169 points
Date : 2024-10-25 15:53 UTC (1 days 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.
| vlovich123 wrote:
| I was responding to what OP wrote:
|
| > Redhat and Gentoo are the only ones that officially
| support it afaik
| 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
| INTPenis wrote:
| It's unfortunately "broken" on purpose even on RHEL. Red Hat
| have made decisions to run init services in unrestricted
| context just to make it easier for their end clients to deploy
| their own services without needing SElinux modules.
|
| In my view all these compromimses only speak to the true
| security of SElinux. The fact that we need to have a website
| called https://stopdisablingselinux.com/ means it's working!
|
| I am one of those weirdos who prefers to learn and adapt to
| SElinux instead of disabling it.
|
| The article in question takes a lot of liberties with complete
| FS access. It's not really applicable to real world server
| security. The focus is on smartphones.
| tetha wrote:
| Mh. I know Linux and SELinux. SELinux has a severe
| documentation issue.
|
| Like, as a user, once you grok filesystem, port and process
| tags, it's easy to navigate most if not all common "strange"
| SELinux errors.
|
| After that I figured, I might be able to implement SELinux
| modules for our in-house services. Just tag config files,
| binaries, logfiles, state files, add a tag for the process,
| link them up with a few rules, easy peasy
|
| I all in all hit a wall harder than the iron curtain. I'd
| have to understand my application on an individual syscall
| level (I think, from like one github gist and a random dudes
| blogpost going into a few details to implement selinux
| modules) to do anything at that level. I spent a week on that
| and figured that I either have to understand kernel
| interfaces and the entire SELinux stack in all details to
| implement my own SELinux modules, or to not implement my own
| SELinux modules.
|
| At that point I figured no one else on the team would have a
| snowballs chance in hell to do any of what I'm looking at and
| accepted SELinux would not be a thing for our internal
| applications.
| 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.
| ykonstant wrote:
| I really wish they resume their (visible) work on Operating
| Systems; if nothing else, it signals the world that OS Security
| is "serious business" when the premier cyber-spy-security
| agency dedicates resources to it. I cannot believe they are
| strapped for money!
| ilbeeper wrote:
| Crowdstrike provided everyone on the planet with a very
| strong signal of the the importance of OS security
| 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.
| orbisvicis wrote:
| That's exactly right - RH is windozifying Linux.
| ruthmarx wrote:
| So is Ubuntu, so is any distro with systemd.
|
| The point though, was if you don't want to learn to use a
| complex system you shouldn't complain when you use it and
| don't understand it.
| orbisvicis wrote:
| RH is doing a lot of good things like unifying the
| NetworkManager configuration for plugins. But some things
| give me pause, such as - and it's been a while so I don't
| quite remember - copying ssh key selection settings to a
| security policy file elsewhere such that those settings
| in the regular config would be ignored. These are ssh-
| specific settings that did not integrate into a global
| "policy", and which were placed in a nonstandard location
| - not ssh.d, which now that I think about it is probably
| another RH invention.
| worthless-trash wrote:
| I think that's the crypto policy configuration which was
| required for some government certification iirc. It's
| been a while but I ran into this too.
|
| There was a document on access.redhat.com that talked
| about it.
| ruthmarx wrote:
| > But some things give me pause, such as - and it's been
| a while so I don't quite remember - copying ssh key
| selection settings to a security policy file elsewhere
| such that those settings in the regular config would be
| ignored.
|
| Yeah, I've always been against that type of crap.
|
| It's why Ubuntu, even Debian, and especially RedHat were
| never really viable distros for me when things like
| Slackware, Alpine and Void exist.
|
| I don't need a ton of abstraction between me and what I'm
| trying to accomplish.
| 3np wrote:
| Similarly, how having systemd-resolved running overrides
| /etc/resolv.conf. Pretty annoying.
| ilbeeper wrote:
| Annoying until you learn to disable it or learn what it
| is good for and how to configure it so that it will work
| for you.
|
| It's annoying because it's a change in system that you
| are familiar with and you can trip on it you if you are
| not familiar with it, not because it is not useful or
| great challenge to configure right.
| fsflover wrote:
| > or use a different distro
|
| For example, Qubes OS: https://qubes-os.org
| orev wrote:
| By default, packages you install from the OS have SELinux
| labels set for correct operation, and sometimes have booleans
| you need to enable to allow more advanced use. Anything you
| install yourself (e.g. tarballs) are completely unrestricted.
| It sounds like you need to get a better understanding of where
| the lines are.
| 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/
| iluvcommunism wrote:
| I've had that POS SELinux block me from logging directly into the
| console with root (nothing wrong with the pwd). Thank VMware for
| snapshots. I hate SELinux. But the job requires it. As for people
| who seem to love it so much, they probably don't have to deal
| with it all the time.
| ruthmarx wrote:
| > As for people who seem to love it so much, they probably
| don't have to deal with it all the time.
|
| Or they put in the time to learn it so they don't get
| frustrated when they get blocked by something, because they
| know how to resolve it.
| hooverd wrote:
| I wish I had the hours to dedicate to every single technology
| I'm using, but alas...
| ruthmarx wrote:
| This is one of those technologies that people shouldn't be
| using if they didn't take the time to learn it.
|
| It's not like say, nginx or a linux distro, where you don't
| need to know the ins and outs to get it up and running.
| _factor wrote:
| We can't ask every car driver to be a mechanic.
| Specialization is born of finite time and is valuable.
| iluvcommunism wrote:
| "Just learn to use it bro" _constantly breaks_ Yeah ok.
| AlienRobot wrote:
| When I used Fedora for desktop, VS Code triggered warnings
| because of a SELinux configuration. Something about using
| writable memory as executable.
|
| The discussion on the topic was disappointing. Chrome does this,
| all Electron apps do this, VS Code does it. It was insisted that
| the warnings were fine because this is insecure and the
| developers should just fix their applications.
|
| I do not have the patience to waste two hours researching every
| single complicated solution that every single application uses to
| make things work just to personally decide whether it's safe
| enough to whitelist it.
|
| Long story short I'm using Mint now.
| Vilian wrote:
| All of that, because of some warnings? And now you're happy
| because you don't see the warnings so you have the false
| sensation of security
| worthless-trash wrote:
| This is the modern world we live in. Decisions like this
| drive life.
| josefx wrote:
| Pointless warning spam drowns out real issues in the logs all
| the time. You cannot expect an end user to fix chromium based
| applications or stop using them, so all you end up doing is
| making the system less usable and less secure.
| mroche wrote:
| There are two components to SELinux alerting mechanisms,
| both of which are documented.
|
| For GUI notifications open the sealert app and disable
| alerts. For journal/syslog reports disable the
| setroubleshoot daemon dispatch plugin for auditd:
| sed -i 's/active.=.yes/active = no/'
| /etc/audit/plugins.d/sedispatch.conf service auditd
| restart
|
| You can also uninstall the setroublshoot-server package
| completely, and all AVC denials will continue be reported
| separately outside of the journal.
| freedomben wrote:
| Sure, but even disabling SE Linux all together seems like a
| lighter and more sensible solution to me than changing
| distros. I doubt those applications are suddenly going to
| stop doing the things deemed insecure because they're
| running on a different distro, so even just allowing those
| actions seems far easier and still better off than changing
| distros. I generally try to fix all SE Linux issues as they
| come up, but when I just need something working and don't
| have time to muck with it, I've disabled it in the past.
| Yes, I know it makes Dan cry, but having people screaming
| for something that they need immediately to do their jobs
| makes _me_ cry.
| Whatarethese wrote:
| The amount of times I've seen setenforce 1 is ridiculous, but not
| suprised.
| echoangle wrote:
| Where does the kwrite() come from? How do you get the privileges
| to write to arbitrary memory addresses?
___________________________________________________________________
(page generated 2024-10-26 23:05 UTC)