25 ms·

SELinux is unmanageable; just turn it off if it gets in your way

• cpncrunch 4y ago
  I came to the same conclusion, but in my case the problem was that there were no audit messages for one particular denial. After a week or two of investigation I finally found the solution. But, I decided that I simply couldn't trust selinux any more, so I turned it off.
• devit 4y ago
  SELinux works well on Android because the OS is delivered by a single entity and unmodifiable, and is maybe fine on a desktop, but on a custom server it seems to me that using VMs or containers as a security boundary is far better since it's trivial to understand and in the case of VMs more secure.
• mindwok 4y ago
  As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as mature as SELinux, but containers aim to provide many of the same benefits that SELinux does (and even more) except in a way that’s much easier to manage. Even better is that these container runtimes often come with SELinux and AppArmor policies out of the box on good Linux distros.
  • devman0 4y ago
    I was about to argue with you until I read to your last point. Totally agree one of the great things about containers is indeed they integrate very well with various Mandatory Access Control implementations SELinux included and don't generally require specialized policies for each app.
  • ximm 4y ago
    I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even though some of them are very high level such as `ProtectSystem`. Containers have made the conceptual shift from allow/deny to isolate/share. Somehow this feels better even though it is effecitvely the same. I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. I am not sure if this is even possible though because many applications are not built with sandboxing in mind. Adding another file somewhere on the system that needs to be accessed is not considered a breaking change by most. So maybe we need a more fundamental shift.
    • zozbot234 4y ago
      > I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. Bubblewrap? FlatPak's sandboxing features are built on it already.
    • tinco 4y ago
      In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container. Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.
      • ximm 4y ago
        What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
  • tpetry 4y ago
    And when everything is in docker you can use SELinux again: A docker container is not allowed to access the host system or access the filesystem of other containers. That‘s the default. SELinux protection without any weird problems.
  • bitcharmer 4y ago
    Container approach is not always feasible, for example when you need to stay on bare metal. There are Linux applications where selinux definitely gets in your way and there are legitimate reasons to turn it off completely. edit: I like how I'm getting down-voted for sharing factual information. No-one in high frequency trading employs containers because it doesn't help soft-realtime, low-latency goals. There are other performance-sensitive domains where containers aren't an option. Sometimes I feel like this place is turning into Reddit.
    • TheDong 4y ago
      > when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.
      • Gigachad 4y ago
        Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.
        • KronisLV 4y ago
          > ...anything that expects to be managing docker inside docker. Now that's an interesting problem to have! If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well. Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind https://github.com/jpetazzo/dind Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches. In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!
  • patrck 4y ago
    A couple sysadm red flags: 1) The article author is Testing in PROD 2) selinux debugging relies on auditd, so sanity checks required. df -P /var/log/audit # has space? tail -1 /var/log/audit/audit.log # is recent? semodule -DB # disable dontaudit setenforce 0 # run the failing test audit2allow -l After which the selinux debugging experience boils down to: mk_semod() { module_name=$1; shift audit2allow -l -m ${module_name} -a > ${module_name}.te $EDITOR ${module_name}.te || return checkmodule -M -m -o ${module_name}.mod ${module_name}.te semodule_package -o ${module_name}.pp -m ${module_name}.mod semodule -i ${module_name}.pp }
    • kelnos 4y ago
      I think you just proved the author's point. That looks entirely inscrutable.
  • seodisparate 4y ago
    As a lightweight alternative to Docker-based (or any container-based) solutions: Try firejail. You can set up a directory that will be the "home" of the sandboxed application you're running, then you can do something like `firejail --private="${HOME}/my_firefox_jail" firefox`. There are built-in profiles for many applications already, and you can customize them (by adding `.local` files, not editing the existing `.profile` files). See the following link for details. https://wiki.archlinux.org/title/Firejail https://wiki.archlinux.org/title/Firejail
    • kaba0 4y ago
      Convenience matter. Without it being automatically on everywhere, it doesn’t protect from much. Sure it can be good for the occasional random software you trust the least, but how many exploitable bugs were found in any of your completely trustable tools? Also, afaik firejail runs as suid, making any possible escape much more serious.
      • seodisparate 4y ago
        [1] discusses firejail running as root: > For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside. > The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping. And I think Docker has a similar problem as mentioned in the "warning" section in [2]: > Warning: Anyone added to the docker group is root equivalent because they can use the docker run --privileged command to start containers with root privileges. For more information see [3] and [4]. [1]: https://github.com/netblue30/firejail/issues/1720 https://github.com/netblue30/firejail/issues/1720 [2]: https://wiki.archlinux.org/title/Docker#Installation https://wiki.archlinux.org/title/Docker#Installation
        • goodpoint 4y ago
          Actually docker is much worse due to the large attack surface.
  • kkfx 4y ago
    Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of course, it's hard to satisfy hw "subdivision" vs sw subdivision, in the past we have tried the hw path with blades for the small side, infiniband and co for the large side and both proved to be not very scalable but the issue is in actual OS design and can only be solved changed that: An OS mush be a single application, with internal namespacing, networking. We have seen it in various past OSes. It's about time to make them again accepting that the IBM model is good only for IBM, witch means for selling stuff to people having no choice but buy or ignoring something better can be done.
    • anonymousDan 4y ago
      Can you elaborate on the scalability problems with infiniband?
      • kkfx 4y ago
        It's not a problem with infiniband but a problem of sw mutating needs vs actual hw assets: matching is hard. Hw cost money so anyone try to be moderately tight, looking at life expectancy and supposed sw changes in that timeframe, but hw and sw have different lifecycle. At a certain point in time sw infra change while hw is still the same, at another point in time available/current iron change but software on it remain the same. In classic times that's just a matter of balancing both, carefully designing both, but in modern time developers just "produce code", operation is pushed aside, communications are constrained often by the policies and the result it's a mess => companies choose "the cloud" witch means outsource the issue to third parties. Those third parties count on the fact that even if anything change in the end a computer is always a computer so they can live on a changing world because if single companies have irregularly changing needs on average the rate of change is similar. Also on scale redundancy needs lower the costs and that's why we switch from classic big iron to desktop crap packed in racks. Now we start seeing more and more the limit of such model, and no solution is here. Big iron is long lost, now way to expensive not much in absolute terms but in demand terms: try to sell a Power system, the customer look at specs and say "hu?! a couple of PCs from nearby grocery store are equally powerful!". Such iron modularity coming from classic mainframes (infiniband in the end is crylink changed a bit by SGI and others) is considered too expensive, on the other side of the spectrum small-board ARM super-blades tentative still results in fails. Until we accept that hw and sw can't really be two separate world and both must be open to being able to interoperate on scale we will not find any really scalable solution. Sw side it's not different: these days is the containers mania days because after many have suffered burn with full-stack virtualization on x86 they look for something with less overhead and equal design: hw-sw decoupled, possibility of run an infra you do not know buy pre-made images/containers from third parties who maintain them without needing to know your infra. The result again is an enormous amount of layers and giant attack surface no one really know how extended it is. Since coms are needed we punch holes here and there, and on the other side "safety features" arrive to compensate, making more complicatedness layers on complicatedness instead of admitting the basic issue: in sw terms our OSes are badly designed for current needs, they are a relic form a long lost past where they aren't even good but just cheaper alternatives to something better. If we ever admit those errors probably we will be able to design modular iron and modern OSes marginalizing those issue, but so far no one want such a nightmarish adventure...
  • zozbot234 4y ago
    AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.
    • porker 4y ago
      It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I specified. It's the only service I've created where this has been necessary, and others write logs, so I have no idea why this one caused errors. If I did something wrong, let me know how this should be handled.
      • db48x 4y ago
        Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message. It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to and thus require you to open specific directories back up. Instead of using ReadWritePaths=, you might prefer to set LogsDirectory=.
        • egberts1 4y ago
          Yet another rabbit hole has emerge. And it is called “systemd”. What a great time to be a Linux system administrator.
          • NoGravitas 4y ago
            Compared to selinux, though, the systemd documentation is excellent, and the tools for observing the state of the system are very good.
  • raesene9 4y ago
    I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface. We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.
    • bonzini 4y ago
      A lot the container breakout CVEs do not affect a system that uses SELinux properly.
      • raesene9 4y ago
        have you seen an analysis of SELinux against the recent set of breakouts? That'd be interesting to see. Definitely the CRI-O one (which is most likely to affect Red Hat based systems) was able to exploit a default OpenShift cluster in my testing.
  • fsflover 4y ago
    > Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way Or just use Qubes OS: https://qubes-os.org https://qubes-os.org.
  • nigma1337 4y ago
    As a completely new admin, could you elaborate on "be very careful with volume mounts"? In the k8s env I run, the filesystem is backed by ceph, which creates persistent volumes that the different pods can claim. Is it just "be careful not to mount docker.sock"?
  • goodpoint 4y ago
    > but containers aim to provide many of the same benefits that SELinux does Absolutely not. They are not designed as security tools in the first place. Especially docker, with its huge attack surface. You are confusing containers with sandboxes. Furthermore they don't implement anything resembling RBAC.
  • mmis1000 4y ago
    Docker actually comes with an apparmor config that disallows you to interact with any files outside of the container. It's not a so strong guarantee compares to inode based approach (selinix), but is still much better than don't have one. And if you enables uid mapping, your permission in the host system is just as high as nobody if there isn't a kernel exploit happened somewhere. But the fact it is nobody is also problematic, because dir mount will be almost alwyas read-only now.
    • cpuguy83 4y ago
      It comes with both an apparmor profile and an SELinux profile. What gets used depends on what's on the system... and I guess you need to actually set the flag on dockerd to enable SELinux.
  • rbanffy 4y ago
    > much easier to manage I would say it's not necessarily easier to manage, but it's much easier to understand, because containers create natural borders between the different software running on the machine.
  • someguydave 4y ago
    By using containers you can multiply your security problems! That is, it does nothing to address security problems latent to each container binary.
• jandrese 4y ago
  > There’s nowhere on the system where you can view the policies and look up why something might or might not work. I always thought I had to be missing something with SELinux because this is what it seemed like to me and that can't be right. My impression is that the documentation for SELinux is extensive in all of the areas that aren't affecting you but it's really hard to nail down exactly what the policies are, what labels are available, which labels you should be using, and generally how everything interacts. Is there a SELinux Wiki somewhere that I've missed that has a simple breakdown of each and every possible label with interactions? Some tool I can use to generate said list?
  • totony 4y ago
    http://www.selinuxproject.org/page/Main_Page http://www.selinuxproject.org/page/Main_Page has some good resources, but most documentation is aimed at policy developers and not end users.
  • emmelaich 4y ago
    You can install the policy source. It ain't easy but it's there.
  • chr15p 4y ago
    sesearch lets you query the rules on a system. sesearch -A will show you every thing that is allowed, and gives you (a lot of) lines like: allow httpd_t httpd_t:dir { getattr ioctl lock open read search }; Which says that things (i.e. processes) with the httpd_t label are allowed to perform getattr, ioctl, lock, open, read, and search operations on directories with the httpd_t label. ps -Z and ls -Z will then list the labels of processes, and the labels of files and directories. If your processes label does not have an allow rule for your file label for the correct action you are denied. The only trick really is that when it reports a label as say "system_u:system_r:httpd_t:s0" thats 4 different colon separated fields and the only one you really care about is the type field "httpd_t", because thats what the rules are defined for (unless you're the NSA or doing Very Interesting things (the other fields are user, role, and security level, but the default Red Hat etc selinux policies dont use them)) There is no wiki with definitive list of labels because they are just strings and the policy writer can call them what they like, even the _t suffix is just a convention to denote the type.
• _8j50 4y ago
  I like apparmor better. Set it up for high attack surface apps like browsers and vms.
  • bragr 4y ago
    I can't say my apparmor experiences have been great. SELinux and Apparmor are just two heads of the same problematic coin. As other comments on here point out, it's easier to have one sane policy for docker and containerize everything else.
    • someguydave 4y ago
      How is your docker policy not something like: “give docker access to everything” ?
    • _8j50 4y ago
      How the hell do I dockerize firefox or vbox? I get it for server workloads but I was talking from a desktop perspective. Even if that is possible seems like even more stuff to manage and troubleshoot. Also, you are not supposed to ise containers as a security boundary??
• nickysielicki 4y ago
  Everyone who has even a slight interest in learning how to use selinux should just go through this CTF-style game: http://selinuxgame.org/ http://selinuxgame.org/
  • colordrops 4y ago
    Ironic (maybe intentional?) that this site doesn't use TLS.
  • josephg 4y ago
    There's something funny about a website about teaching security practices being unavailable through HTTPS. It looks like the website is hosted by github pages, and the author didn't bother setting up SSL correctly.
    • vermilingua 4y ago
      Is there anything on the site that needs to be secured with TLS? There's no authentication, no user details, why would it need to be secured?
      • deniska 4y ago
        So that your ISP, or someone else along the way, doesn't put a cryptocurrency miner into the page source.
      • withinrafael 4y ago
        Someone in the middle could teach you a variant of the material in hopes of creating more insecure servers out there. Or perhaps link to an "official companion app|pdf|exe" on the page.
        • d2wa 4y ago
          Or more likely: insert a cryptocoin miner script or ads.
      • 4y ago
• jlund-molfese 4y ago
  Off-topic, but the polite “disable your adblocker” message unobtrusively displayed at the end of the article is a nice way to do it. Lets me know I can support the site that way without hindering the reading experience.
• csours 4y ago
  Is the information being hidden intentionally to prevent attackers from gaining a toe-hold?
  • dale_glass 4y ago
    No, author is just incompetent.
• pjmlp 4y ago
  Well, Android has it always turned on for several years now.
  • beermonster 4y ago
    Mobile applications require various permissions which can be enforced via SELinux. SELinux policy can also be written to mitigate many vulnerabilities and vulnerability classes/vectors. Over 40% [1] of Android users may no longer be receiving important security updates, potentially putting them at risk of malware, data loss and cyber attacks. Seems to make sense to have it enabled on Android based on the above. [1] https://www.which.co.uk/news/2020/03/more-than-one-billion-android-devices-at-risk-of-malware-threats/ https://www.which.co.uk/news/2020/03/more-than-one-billion-a...
    • pjmlp 4y ago
      Another reasons it is turned on, alongside seccomp, is to make sure app developers don't mistake Android for Linux, something that Termux guys aren't very found of. https://android-developers.googleblog.com/2016/06/android-changes-for-ndk-developers.html https://android-developers.googleblog.com/2016/06/android-ch... https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html https://android-developers.googleblog.com/2017/07/seccomp-fi...
    • josephcsible 4y ago
      > Mobile applications require various permissions which can be enforced via SELinux. What do you mean by this? SELinux can only deny things that would otherwise be allowed; it can never allow required permissions that would otherwise be denied.
  • pajko 4y ago
    Yep, building and investigating an AOSP firmware is the best way to learn how SELinux works and how it can be configured. https://source.android.com/security/selinux/build https://source.android.com/security/selinux/build
  • kllrnohj 4y ago
• glowingly 4y ago
  Like others here, I had a similar experience. I setup a simple minecraft server on a SELinux secured OS. So far, so good. I wanted to setup a systemd service to startup and shutdown the minecraft server. After ~1 hour of work later, I came to the conclusion that I was going to disable SELinux. Another hour later, I disabled SELinux. Much as the article mentions, there didn't seem to be much good help, especially w.r.t. learning what the incantations meant and how to use them properly outside of a narrow path. Similarly, I did not have any decent way of introspecting what was going on in there. The error messages were of the "you must google this to even have a remote chance of figuring out what it means at all." I understand SELinux is probably designed for enterprise or organizational specialists and not for normies to touch. It just seemed a bit too extreme towards that end.
  • totony 4y ago
    You hit the main issue with selinux: most documentation is aimed at policy developers and not end users. Your main issue was that you were trying to adapt the reference policy without knowing its inner workings.
  • _tom_ 4y ago
    Or designed to sell those services to you.
  • stjohnswarts 4y ago
    Apparmor is -much- easier to write policies for; even more so if you use one of the ubuntu based distros that have decent rules already set up for most apps you'd use.
  • rmetzler 4y ago
    Hey, a few years ago, but after the 1.0 release, even the Kubernetes docs mentioned to turn SELinux off. It’s just that SELinux documentation (something like a cookbook) is (or was) very hard to find on the internet.
  • faebi 4y ago
    I was in a similar situation. It always takes me way to long to find out that SELinux is responsible for a seemingly impossible to understand error behavior, until I give up, ask a colleague, he mentions SELinux and then it's suddenly obvious. So my conclusion is that the fail-behaviour is just not good. I would prefer my process to be killed with a nice clear error message somewhere. I think it all about giving the user the right information instead of failing silently.
• ungamedplayer 4y ago
  The advice is poor and shows the authors lack of basic ability to understand basic selinux tooling. It's doubly bad because most people running modern Linux run their apps in containers and don't need to understand it as they don't run into problems. I'd this really is what gets the pageviews maybe someone should write a how-to on disabling all permissions because it's too hard.
  • durgampudi 4y ago
  • ungamedplayer 4y ago
    Should I agree with the hivemind like this ? Oh, What I meant to say is. The author is correct, selinux is too hard. I too am incompetent and unable to understand the many examples that demonstrate solving selinux issues. What we really need is a shittier solution that lets good programs work while stopping bad people from doing bad things by using psychic powers and having a deep understanding of software that is yet to be written.
    • dale_glass 4y ago
      Author is correct that SELinux is not trivial and takes work to figure out. Author is full of it in that they're obviously not aware of the tooling and information available. Eg: All of this is wrong: > Fedora Linux. There’s nowhere on the system where you can view the policies and look up why something might or might not work. You can install the policy's source and look at it all you want. There are also tools to examine the current policy. > The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever? You get that in the logs. What you get is an inode number, which isn't very user friendly, but it's very much there. SELinux has tooling to turn the log messages into something nicer to work with. > So, you run the audit2allow command as instructed, and end up with some policy blob files. > God only knows what changes the blobs do; you can’t be expected to, nor are you given enough information to evaluate them. This is also wrong, along with the blob you get a text file. TL;DR: The author has a minimal point, but clearly hasn't read the docs. Help and tooling is available and not that obscure.
• noasaservice 4y ago
  Or, you could use setroubleshoot to learn it, and manage a linux machine properly. But that's hard work. Guess it's another SELINUX=disabled
• dylan604 4y ago
  After using CentOS for years, I have come to establish a debugging rule: If things just don't make sense, check if you're fighting SELinux policy. It's just one of those things that you beat your head on the desk after crashing into multiple brick walls that eventually works its way into your debugging process. I guess it just shows how effective SELinux is if it is preventing the admin from doing something. /s
  • scrapheap 4y ago
    Sysadmin Rule #1 - Is it SELinux? Sysadmin Rule #2 - Is it systemd? Sysadmin Rule #3 - Have you checked the logs?
    • koffiezet 4y ago
      Where's the time where you could just assume it was DNS.
      • nix23 4y ago
        And Time..ntp etc.... ;)
        • tremon 4y ago
          That's covered by rule #2 (systemd-timedated) ;)
      • garaetjjte 4y ago
        That's covered by rule #2 (systemd-resolved)
• staticassertion 4y ago
  I've always preferred apparmor. SELinux has always seemed radically more complex for very little benefit, unless you have a tightly constrained OS (like Android, where the VM does most of the work and every app has the same sort of security policy) or a team of admins working full time to maintain it (again, like Android). Apparmor is weak in all the same ways SELinux is weak, at least in terms of the ways that actually matter - that is to say, a kernel exploit is the simplest way out of either. But anyone can write an apparmor profile for any program in an hour, and if you actually know wtf you're doing you can build very strong profiles and trivially test and maintain them. SELinux is "good" in that if you are building a system like Android, great, consumers get very tight policies for free, and SELinux is ultimately more expressive. But I think 99% of companies looking at an LSM MAC should probably roll apparmor.
  • RVuRnvbM2e 4y ago
    This is exactly my experience. To expand a little, for a vertically integrated OS like Android or RHEL (official packages only!) SELinux can work. For a sysadmin trying to configure a custom service or anything outside official repositories then AppArmor is actually usable where SELinux isn't. But what you probably want is a Docker (or Podman) container, which gets you 90% of the hardening with 1% of the effort. If a container isn't viable for whatever reason, then a systemd "contained" service is also very easy to configure. See `man systemd.exec`.
  • bboozzoo 4y ago
    I think my main problems with AppArmor are the feature set isn't coherent across all distros that use it and it isn't integrated too well with audit tools. OpenSUSE ships distro patches that are a major hack to make ausearch properly show AA denials, while others need to look at dmesg and remember to disable printk ratelimit. The supported feature set is fun, the kernel mainline vs Ubuntu vs SUSE feature sets differ a lot. Ubuntu supports fine grained socket mediation (as in specific ops) & dbus. OpenSUSE supports some of the socket mediation, but as life has demonstrated some rules that work on Ubuntu are incorrectly downgraded and for instance all unix socket access gets blocked (though thanks to the AppArmor folks this got fixed now). Arch which I'm considering to be close to mainline has no dbus and no fine socket mediation. In theory one can use the same policy file on all systems, but the way it gets downgraded is not always predictable. At least the features are somewhat discoverable though /sys/kernel/security/apparmor tree, but I don't know what happens when say the kernel reports dbus mediation, but dbus-daemon was built without it. Then there are also some missing features, I think the abstract socket mediation is still not there. Lastly, the parser is super slow and memory hungry, especially when throwing some AARE heavy profiles at it. It happens that Ubuntu Core makes heavy use of apparmor profiles to lock down snaps on embedded Linux devices, and all the timings data that we collect show calling out to apparmor parser taking the largest chunk of the snap installation time. FWIW mediation of dbus & network is already supported by SELinux in all implementations I've tried, but then SELinux has a separate set of warts. Eg. trying to use the same source policy and building it on hosts with different tooling/refpolicy. Using `optional_policy` doesn't cut it if types are not known at all, and as debugged with good folks from #selinux, the only way to work around this was using `ifndef` and passing defines to m4 interpreter.
• josephcsible 4y ago
  SELinux has a horrible misfeature called dontaudit, that lets policies using it deny actions without any evidence being logged anywhere. Because of the existence of this, the only reliable way to know if a problem is being caused by SELinux is to temporarily disable it and see if the problem goes away.
  • cube00 4y ago
    After years of setting permissive on my personal machine I wanted to do the right thing and set it up properly. I watched the presentations and all seemed so reasonable. It's there to help you, audit2allow will help you out even further if you need to allow something. Look at how detailed those error messages are explaining the problem and the solutions. I thought I was going crazy that things weren't working and there were no denials in the log. After much pulling of hair I finally found out about dontaudit, I felt so cheated, it wasn't even playing fair at that point. For anyone else hitting this, you can use semodule to disable dontaudit in step 4 [1] [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux#identifying-selinux-denials_troubleshooting-problems-related-to-selinux https://access.redhat.com/documentation/en-us/red_hat_enterp...
  • tremon 4y ago
    Not only that, but the official policies rely on dontaudit rules because there are known policy violations that are in fact harmless (like processes scanning entire directories, or attempting to open a file in various locations). So disabling dontaudit means your logs will get cluttered with non-related error messages that were up to then silently ignored.
• smcleod 4y ago
  SELinux really isn't that hard, especially if you spend a very short time to understand the basic concepts and commands. SELinux for mere mortals: https://youtu.be/MxjenQ31b70 https://youtu.be/MxjenQ31b70
• durgampudi 4y ago
• dschuetz 4y ago
  The gist of the problems is that the policies are not transparent (probably due to security reasons?) to the user/admin, did I get that right? And that there's a difference in enforcement between user policies and policies provided by the distribution? All this sounds to me like a good idea that got lost in the implementation. If you have no way to look up which policies are in effect and what is labeled and how, something that even Windows 10 gets right, then yeah. SELinux is a toxic mess.
  • loeg 4y ago
    > policies are not transparent (probably due to security reasons?) Maybe, but also it just seems like the SELinux developers prefer a byzantine system.
  • dale_glass 4y ago
    Which is complete bullshit, the blog writer is just uninformed. There are tools to examine the policy, and you can get the source to the entire thing. Though it's rather big and complex, but it's certainly there.
  • d2wa 4y ago
    > The gist of the problems is that the policies are not transparent Yes. > (probably due to security reasons?) to the user/admin, did I get that right? No, that isn’t the reason. They’re open source. The policies are, simply put, compiled binary blobs from a comprehensive set of allow-rules and label-path definitions. The complexity of analyzing and difficulty in overriding these complex rulesets is the problem. There are tools for interacting with the system, but good luck figuring out what they’re even called. All the tools are optimized for the ruleset developers and not the sysadmins that have to play by the rules (and are never told what the rules are). Answering the question, “What do I need to label files that should be read by program X?” is waaay to hard. You’re expected to put your files in certain locations and then some things work out-of-the-box. However, there’s no documentation on where you’re supposed to put the files. Sure, /var/www is where you put your website files by convention. Apache can read from that directory. But what if you put it in /var/web? You can relabel the directory, but it’s not at all apperent why everything grinds to a halt when you do. The /var/www dir is owned and readable by the apache user, but Apache still says complains it can’t read it. That’s the SELinux MAC in action blocking you from doing something totally normal just because you didn’t follow the strict rulesets (that no one told you about).
• silisili 4y ago
  Longtime SA, constantly ribbed or outright insulted for my absolute hatred of SELinux. Yes, I just turn it off first thing. Well, used to when stuck with RHEL environments. If you want people to adopt and really use something at large, you need to make it simple, explain when and why it's useful, and document it well. SELinux doesn't do any of that particularly well. And now that most things are effectively running on a vm inside a vm, the use case seems dwindling even further. I for one will not miss it.
  • dale_glass 4y ago
    Security can't be made simple. At the core what SELinux does is simply enforcing a policy. A list of "Should X do Y to Z?". This is something that can't be implemented with just file permissions. What SELinux does is sandboxing every process it controls. For instance, my cupsd is running as root. It's accepting connections on port 631. If it started accepting connections on port 22, that's probably a bad thing. If it started messing around with /etc/passwd and /etc/shadow, that's probably not good either. It probably also has no business with my GPG keys, or /dev/sda. But under the Unix permission model, if it runs as root, there's nothing you can do about it. It's root, it gets the entire system. If it has a hole, that's that. SELinux first applies labels to stuff, then defines what actions can be done on what. So under SELinux there's a rule that says "A process with the label "cupsd_t can listen on a port labeled ipp_port_t". That's what lets it listen there, and absent a rule that allows it to listen on the ssh port, it's denied even if running as root. So with a well implemented policy, if somebody exploits your cupsd, they can waste your paper. But despite it running as root they can't run a shell, can't open ports, can't mess with your password database, and can't install its own kernel driver. With the right rules, the attacker can find themselves at a dead end, where there's nothing useful they can do. You can to some extent do this kind of thing with containers, but it really amounts to doing the same kind of work in the end to a large extent. If your container's security is at all useful you'll have to tell the system what should the cupsd container be able to do, in a very precise manner, and not just "eh, it can have root access to everything". At that point you've got another SELinux-like system to deal with.
    • silisili 4y ago
• fargle 4y ago
  How can I trust some opaque policy I cannot see? Not just trust that it is well intentioned not evil, (Oracle Linux?), but that it does what it says. And does what I need and that the opaque developers have correctly envisioned what I need to do. Security by obscurity is worse than none at all. Security by buying an "Enterprise" product is worse than that. What SELinux says is "real MAC security is super complicated, but don't worry we've taken care of all that for you, but you can't understand it or change anything". What I say is "easy peasy; if you access the machine you're root. Make sure that either it doesn't happen or it doesn't matter".
  • prmoustache 4y ago
    > but you can't understand it or change anything" That is not true. SELinux is not hard to understand nor change. Most of the issues you might encounter are simply solved by changing a label in a file or directory. It is just not straightforward to debug and understand if you don't know it is there. I think most people who complain about it are multi distros/OS users and just only realize after losing precious time that an issue is selinux related.
    • d2wa 4y ago
      But what am I, as the sysadmin, supposed to label things? Even if I know that I probably need to apply some labels, how do I find out what the policies are? What labels can interact with this program? You can turn to Google and find some incantations in a blog or forum post from ten years ago, but you can‘t easily see which labels a program is allowed to interact with or not. (If you even know to ask that question.)
      • dale_glass 4y ago
        Fedora comes with manpages. So for instance, say you want to place http pages outside of /var/www. Fedora comes with the selinux-policy-doc package, which gives you the httpd_selinux manpage: https://linux.die.net/man/8/httpd_selinux https://linux.die.net/man/8/httpd_selinux It's a tad dense, but in the Sharing Files you can find a section explaining what context is used and for what. You can also look at the existing context, eg: $ ls -laZ /var/www total 4 drwxr-xr-x. 4 root root system_u:object_r:httpd_sys_content_t:s0 33 mar 17 17:32 . drwxr-xr-x. 21 root root system_u:object_r:var_t:s0 4096 abr 18 10:57 .. drwxr-xr-x. 2 root root system_u:object_r:httpd_sys_script_exec_t:s0 6 mar 17 17:32 cgi-bin drwxr-xr-x. 2 root root system_u:object_r:httpd_sys_content_t:s0 6 mar 17 17:32 html And copy those for your own use.
• pkrumins 4y ago
  My advice is to ALWAYS turn it off. As soon as you install a new system, turn it off (together with systemd).
  • josephcsible 4y ago
    > turn it off (together with systemd) How practical is just turning off systemd today? I hate it too, but hasn't Red Hat basically strong-armed so many important Linux components into adding a hard-dep on it that your only way of avoiding it is to use a distro purpose-built to (e.g., Devuan)?
    • t-3 4y ago
      Systemd is only really required if you want to run gnome or kde easily. It's not an issue otherwise. Probably more trouble than it's worth to replace it in a distro that uses it by default though!
      • Gigachad 4y ago
        I don't think as a user you actually can remove systemd at all. Everything is set up to work with it. Removing systemd would be closer to forking the distro and maintaining it yourself. If you wanted to avoid systemd you would have to pick a distro which doesn't use it.
  • shp0ngle 4y ago
    >As soon as you install a new system, turn it off good advice > together with systemd lol why
    • nix23 4y ago
      It's a terrible advice, i really hope he's not a system admin.
      • pkrumins 4y ago
        I run thousands of severs. None of them have SELinux or systemd. It’s banned tech.
• throwaway787544 4y ago
  Operating system security was important back before VMs became cheap. At this point you are really wasting time if you invest significant effort in host security. It's the new network security. Separate concerns into VMs and network connections separated by strong authentication, authorization and encryption, and practice least privilege. It doesn't matter if your OS or containers are made of security swiss cheese as long as compromising one thing doesn't lead to compromising another. For containers you need Firecracker VMs; there is no other strong isolation for Linux containers, everything else is pretty easy to pop.
  • nix23 4y ago
    >It doesn't matter if your OS or containers are made of security swiss cheese as long as compromising one thing doesn't lead to compromising another. I hope you never work with customer related data.
  • fsociety 4y ago
    I’ve heard several high-level security engineers take this stance in organizations with stringent security requirements. There may be some truth here when prioritizing work, but I have yet to see strong authn/authz prevent red teams from wrecking havoc. It’s too complex. We like to think of systems as being fairly constrained, but in practice I am not convinced that is true. Once you start adding other business functions to your environment, like observability, you can introduce non-obvious gaps in your policies. Would having OS security completely prevent an attacker from wrecking havoc? Probably not. But it would make it much more difficult. It can also protect you from container/VM escapes. Are SELinux policies complex? Yes, but they are constrained to a host’s system and are yet another layer of defense that can be used to secure software. I’ve seen again and again how an SELinux policy can prevent an exploit from causing harm. It can also be an effective and quick way to mitigate risks from a new 0-day being posted while software teams work on patching. I am fairly convinced, or bullish, that making SELinux easier to configure is a solvable problem. The biggest hurdle to it is this puzzling movement within security to avoid OS-level controls and instead focus on network-level controls. It puzzles me why a well-resourced org thinks you can only invest in one or the other.
• kbenson 4y ago
  I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), you set the system to permissive mode and let it run with the app long enough that you think you've hit all the use cases, and then you use ausearch and audit2allow to generate a module for it. And bi, while the selinux audit log entries (which ausearch shows) aren't super clear, you can learn to interpret the gist of them, and piping them to audit2why and audit2allow gives more context. The real "trick" in the above is to make sure you run the system in permissive mode for a while. Otherwise you'll usually only see the first deny in a code path which the app will then fail on, and you won't see subsequent ones. Permissive mode means nothing is actually denied, but all thing that would be denials are logged as such. For things that ship with the OS repos for RHEL and derivatives, my experience is that very rarely are there problems or things that are not obvious to fix (running errors through audit2why will tell you when there's a boolean to toggle to allow what you want, such as outbound tcp connections from the http context that is causing some PHP app to malfunction).
  • XorNot 4y ago
    You can also write a stub policy which is permissive for all actions, with logging turned on. This means you can run just the one application in permissive mode, get a sense of its behavior, and then lock it down.
  • autoexec 4y ago
    > and then you use ausearch and audit2allow to generate a module for it. And bi, while the selinux audit log entries (which ausearch shows) aren't super clear, That still sounds pretty complicated for most people. I mean, I know a lot of otherwise capable people who think NoScript is too much to manage and that's something I've heard repeated online many times. That's just clicks, and only when you actually need to allow something. I would think that if even the people who own websites where they write entire articles about linux find something over-complicated and poorly documented most computer users wont stand a chance.
• XorNot 4y ago
  Honestly I thought this was going to be about the problems of fully utilizing SELinux. There are bits of SELinux which are just missing - like a shared network policy server, or the various concepts of transiting SELinux contexts across things like network links to provide network-wide security. SELinux is one of those things that makes total sense to me, but the implementation just leaves so much to be desired - i.e. basically no practical usages of "users" in an SELinux context even though the concept is there.
• technion 4y ago
  The reason I always had SELinux turned off: I would either run Ubuntu, Arch, of Amazon Linux. The Ubuntu story is not great, and you can see you're swimming against the tide of common deployments: https://wiki.ubuntu.com/SELinux https://wiki.ubuntu.com/SELinux Arch doesn't ship with the tooling in the distro itself: https://wiki.archlinux.org/title/SELinux https://wiki.archlinux.org/title/SELinux And Amazon has just released "Amazon Linux 2" which includes "now supports SELinux as a feature".
  • mhitza 4y ago
    Next version of Amazon Linux (2022) will have SELinux enabled by default.
• sydthrowaway 4y ago
  How does SElinux compare to Secure Boot / SIP?
  • ungamedplayer 4y ago
    Not related.
  • beermonster 4y ago
    Security-Enhanced Linux (SELinux) is a security architecture for Linux systems that allows administrators to have more control over who can access the system. It was originally developed by the NSA. Secure Boot and SIP are about boot integrity preventing malware early on in the boot process [1] [1] https://www.rodsbooks.com/refind/secureboot.html https://www.rodsbooks.com/refind/secureboot.html
  • microtonal 4y ago
    SELinux and Secure Boot are largely orthogonal. Secure Boot can be used to establish a chain of trust to guarantee that you are running software that is not tampered (using asymmetric cryptography). For example, Secure Boot can verify that the bootloader is an unmodified blob from a trusted vendor. In turn, the bootloader can verify the kernel. The kernel can verify modules/extensions. In principle, you could extend this chain to ordinary programs. You can use SELinux without Secure Boot and Secure Boot without SELinux. Secure Boot can make SELinux more effective, because you can use it to verify that the kernel is not tampered with, so you know that it is properly enforcing the SELinux policies. You could also verify cryptographically whether a policy is not tampered with, but I am not sure if that is currently supported. The comparison between SELinux and SIP is a bit more complicated. SELinux is a security framework that allows you to write all kinds of policies, whereas SIP is a very specific set of defenses. On of the main features of SIP is that it makes certain system paths unwritable for every process that doesn't have the right entitlements, including processes with PID 0 (root), unless they have the the necessary entitlements [1]. Since SELinux is a generic security framework, you can implement something similar to SIP's path protection using SELinux. For example, system paths could be labeled with a special label and writes can be restricted to processes with a particular SELinux context. More concretely, you could use SELinux to forbid that any process, including root processes, can write to a system path like /usr/bin. Then you could allow the security context in which DNF/RPM (the Fedora package manager) run to modify system paths like /usr/bin [2]. [1] SIP does more stuff, like disallowing unsigned kernel extensions, preventing code injection, etc. [2] Russell Coker has set up an SSH machine for which he gives away the root password. But you can't do much with it, because the SELinux policy prevents you: https://www.coker.com.au/selinux/play.html https://www.coker.com.au/selinux/play.html
• ReganLaitila 4y ago
  the linux fiefdoms have a serious UX problem. SELinux being a prime example. As the article articulates, no wonder why people just turn it off. If your subsystems are not consistent, discoverable, palpable, and most important logical your setting yourself up for lousy adoption. And just "reading the docs" does not solve this problem. Your subsystem does not get to consume my professional time slice. The reason docker became the de facto entry point into containerization in yesteryear is because if you were dealing with 'containers' you were dealing with the 'docker' cli entry point. Everything you did with linux containers in the (mainstream) came from 'docker' and you can '--help' to your hearts content -or- google as much as you required with others that had the same shared experience with 'docker'. We've moved on in recent years but its important to remember the power of a well described, but imperfect interface. SELinux has none of this mindshare. What is my canonical entrypoint to SELinux on any particular distro? There is none. I have to specifically know to install support packages for 'audit2allow' or 'audit2why' to do any reasonable troubleshooting on why a processes wont start. Why? Because any raw logs are so chocked with implementation details as a administrator I cannot make a real-world decision on what is broken on the system. Sysadmins do not start every day thinking about SELinux and memorizing its maze of tools and procedures. Something is starting to smell here... For SELinux I need to know about, and sometimes explicitly install, half a dozen cli tools to administer selinux. Most of which don't follow any particular naming convention or entry point. I now need to learn a completely new markup for policy AND compile them AND install them using other esoteric tools . I need to explicitly refresh system state after making any changes, and return to my blunt 'audit2why' what-is-this tool to figure out if I did anything right. The principles of SELinux are fine. The UX of SELinux in terms of getting shit done day to day is not.
  • egberts1 4y ago
    Right, right, and right. Even after mastering all the fundamentals of SELinux, six month later a different audit-related problem surfaced and “what was that command again?” This link often saves me: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux#identifying-selinux-denials_troubleshooting-problems-related-to-selinux https://access.redhat.com/documentation/en-us/red_hat_enterp... In fact, I condensed it to the following steps (outlined elsewhere in this OP by patrck, new HN user): couple sysadm red flags: 1) The article author is Testing in PROD 2) selinux debugging relies on auditd, so sanity checks required. df -P /var/log/audit # has space? tail -1 /var/log/audit/audit.log # is recent? semodule -DB # disable dontaudit setenforce 0 # run the failing test audit2allow -l After which the selinux debugging experience boils down to: mk_semod() { module_name=$1; shift audit2allow -l -m ${module_name} -a > ${module_name}.te $EDITOR ${module_name}.te || return checkmodule -M -m -o ${module_name}.mod ${module_name}.te semodule_package -o ${module_name}.pp -m ${module_name}.mod semodule -i ${module_name}.pp }
• bayindirh 4y ago
  This is bad advice. SELinux might be hard, but it's neither unmanageable, nor it gets in your way when configured correctly. I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. Yes, it has a learning curve, but it's worth it.
  • KronisLV 4y ago
    > Yes, it has a learning curve, but it's worth it. That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use. For people who don't work in banks and whatnot, the choice is probably rather simple to make, they'll just prefer to do whatever will let their code and software run as they want (be it permissive mode or disabling it). In those circumstances, SELinux can be little more than a nuisance and a roadblock, something that they didn't ask for and don't want or care for. When security is paramount, however, things are a bit different.
    • bayindirh 4y ago
      > That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use. Of course, horses for courses. That's always implied, and I always keep that in mind. However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst. Also, I find having a background knowledge about these technologies beneficial. Having more tools under one's belt is never a disadvantage. It'll give you abilities in the best case, and provide you perspective in the worst.
      • KronisLV 4y ago
        > However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst. Agreed, though partially. Those two technologies don't have to be mutually exclusive, though they sometimes are considered to be (e.g. working around the "system limitations" by using containers, when both could work in unison). There are cases where you'll want containers AND SELinux/AppArmor. There are cases where you'll want full blown VMs. And even in regards to containers, there are multiple classes of technologies to consider: LXC/LXD, jails (BSD), containerd/Podman, Firecracker/gVisor and so on. And also approaches, like rootless containers, user remapping etc. My point largely is that people will try to "get things done", everything that impedes them from doing that be damned (in their eyes)!
• ohuf 4y ago
  The question is: what good is a security system that tells me to "just allow whatever the problem is", once a problem comes up? Without being able to see the specifics of a request and blindly following the whitelisting I could end up allowing some hacked module access to critical files without knowing. Opening the system to exactly the dangers I'm seeking to stop.
• dale_glass 4y ago
  I don't think I agree. I've been running things with SELinux enabled for more than a decade, haven't really had problems. The issue with SELinux is that it's security, and security is a complex issue that requires understanding what you're doing and why. It's not a problem domain that's friendly to the approach of poking at random until somehow things start working. It's not really different from filesystem permissions actually. Why not 'chmod 777 /etc/shadow' to get yourself out of a problem? That question can only be properly answered by knowing what /etc/shadow is for, and why it's a bad thing for everyone to read and write it. SELinux just forces you to have to understand the system in terms of what operations a program should be able to do on what. Should Apache serve your ssh private key files? Should a random tool be able to listen on port 8080? There's really no instant answers to questions like that. You have to understand what Apache is, what ssh keys are, and who is supposed to access them. If you have a compromise, you may need to do some forensics and figure out what happened, and that will require answering such questions anyway, at a most inconvenient time. Where did they get in? How did they escalate privileges? How did they get their hands on your data? Is there still a backdoor somewhere on the system? Why is that process listening on that port? And by the way, audit2allow produces text files, which it proceeds to automatically compile for you. Right next to the binary blob there's a text file with the policy, you can read that. Ok, let's look into this in more depth. > At the heart of the problem is that the SELinux policies themselves are sort of magical. The policies have probably been provided by the maintainers of your Linux distribution, e.g., Fedora Linux. There’s nowhere on the system where you can view the policies and look up why something might or might not work. Yeah there is, you can install the policy's source and look at it all you want. It's complex, granted, but it's very much there. There's also tooling to examine the current one, like sesearch. > The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever? You do have that information. It's specified as an inode number for performance reasons, which isn't terribly user friendly. Which is why there's tooling to turn those obscure log entries into something much more readable, such as the mentioned sealert. It's even mentioned in the logs. > So, you run the audit2allow command as instructed, and end up with some policy blob files. > God only knows what changes the blobs do; you can’t be expected to, nor are you given enough information to evaluate them. Wrong, the information is right there in text. audit2allow compiled it into a binary, true. But right next to it you'll find the source, in the .te file. And for most cases, it's a short, quite understandable one. > Then what do you do? You don’t know what the module did, where it was installed, or how to remove it. That seems like a problem of not reading the docs. I mean, there's the semodule command for that. The blog author's problem is that they're trying their best to do the absolutely minimum possible. Which in a way I understand, but doesn't make them informed on the subject matter. It's like writing code by randomly changing stuff without understanding until the compiler finally shuts up. Yeah, sometimes it gets your assignment a bit closer to done, but most of the time the result is crap because randomly messing with stuff isn't a replacement for understanding. Most of what they complain about have tooling, documentation and solutions. They're just not using them.
• modderation 4y ago
  For anyone curious or learning about SELinux, I highly recommend the SELinux Coloring Book [1] as an overview of core concepts. It doesn't go into any of the commands or mechanics of interacting with SELinux, but it has some simple and clear examples of objects, labels, and enforcement types. [1] https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf https://people.redhat.com/duffy/selinux/selinux-coloring-boo...
  • RVuRnvbM2e 4y ago
    I've always found that the concepts are not the difficult part of SELinux. Instead it's the complexity of the configuration and tooling which is always a headache.
    • d2wa 4y ago
      > I've always found that the concepts are not the difficult part of SELinux. There’s tons of good information on this part. > Instead it's the complexity of the configuration and tooling which is always a headache. There’s practically nothing on this. `man selinux` lists some of the tools (last updated in 2005) in “see also” section. On Fedora, half the referenced man pages are missing, though. You’ll need to read a book (or a book’s worth of man pages) to get anywhere.
• deleted 4y ago
  [deleted]
• scrapheap 4y ago
  Does anyone have any examples of where SELinux saved the day? I appreciate that some of the time you'd never know, but I am curious if anyone has any real life examples where it stopped an attacker.
  • bravetraveler 4y ago
    For me, nothing too solid but it makes me sleep better. Not so much an attacker but bad actor(s)... It has saved us from having people with expected (limited) access to systems from spawning services listening on the network that shouldn't be there Granted, we have a default drop policy in the firewall, so it shouldn't really matter in a sense. I like the approach of not having the process rather than preventing access to it The attacks could be worse. For example, some users SSH access was compromised and the attacker wants to use it -- opening a reverse tunnel on localhost out of the environment over their SSH connection... bypassing the usual perimeter for egress. SELinux should provide some nice control over this that would be independent of service
  • microtonal 4y ago
    https://www.redhat.com/en/blog/selinux-mitigates-container-vulnerability https://www.redhat.com/en/blog/selinux-mitigates-container-v... https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/ https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-s... https://danwalsh.livejournal.com/30565.html https://danwalsh.livejournal.com/30565.html
• m1keil 4y ago
  I think SELinux can have its place on servers, but is a tough sell on the desktop.
• bravetraveler 4y ago
  Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare. I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other controls (eg: network isolation) aren't as robust. For business use, it's probably worth some investment. Any serious compliance program will probably want an explanation for why you aren't using it/equivalent. It's not some amorphous thing, it can be learned and handled. I used to routinely disable it but I haven't in years There are clearly defined objects and areas of responsibility. It's just buried under piles of documentation semanage and all of the other tools are indeed cryptic, but you can generally get by with two steps: - Identifying triggered hits - restore contexts / update the policy as appropriate for this use case I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this. A lot of it I can't even articulate that well, I've just developed a set of patterns Edit; obligatory mention: https://stopdisablingselinux.com/ https://stopdisablingselinux.com/
  • nottorp 4y ago
    > I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this. ... and that's the problem. If something requires two weeks of training it's not hobbyist / small business friendly.
    • bravetraveler 4y ago
      It's definitely a bit of a problem that it takes as much research to command as it does... but I don't believe it's so grand. The distribution provided policies offer some sane defaults, smaller shops like this are less likely to be writing in-house software breaking the mold. When they do run into a problem though it's bigger, because unless their people have been doing enterprise-y things, they don't really get the necessary exposure
  • evanreichard 4y ago
    It's been years since I was responsible for administering Linux Servers, but half the issues I ran into were generally fixed with `restorecon`. I used to be that "never disable SELinux" person, but I've since become a bit more pragmatic. But I still think you should at least spend a bit of time trying to get it to work before defaulting to `setenforce 0`. I'm a Detection and Response Engineer now, Analyst for several years prior, and I've seen several incidents that would have been stopped by SELinux. Almost all of them were web shells or web app based RCEs. E.g. https://nvd.nist.gov/vuln/detail/cve-2019-3396 https://nvd.nist.gov/vuln/detail/cve-2019-3396
• AceJohnny2 4y ago
  I see a few obvious areas of improvement, all of which are "implementation details" and don't undermine the core principles of SELinux. > The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever? Improve logging in the SELinux system. Clearly it was able to map the program/files to labels, why aren't those programs/files provided in the error message? > There’s nowhere on the system where you can view the policies and look up why something might or might not work. Improve SELinux's policy analysis tools. As it is, it appears `seinfo` and `sesearch` provide too much detail and are impossible for non-experts to use. Are there alternatives that any sysadmin can use? > A package’s SELinux policy is — most often — not part of the package but is installed as part of a larger meta package containing tens of thousands of policies (e.g., the Fedora Linux project’s selinux-policy mega-package). Policy should be included with the software package (or have a clear, computer-resolvable link to the package the policy applies to). Seems to me that SELinux is an afterthought in most distributions, which I can understand in volunteer/community-driven distributions, less in Enterprise ones. How does RHEL do it? -- However, the fact that these problems remain decades after the introduction of SELinux (2000!), indicate a lack of will by the Enterprise Linux/Security industry. Considering its origins at NSA, which I'm sure is willing to train its sysadmins and not bothered by its obtuseness, I'm not surprised.
  • AceJohnny2 4y ago
    Tangentially, SELinux vs AppArmor vs Tomoyo demonstrates a fundamental challenge of the Linux kernel development model, where the kernel is developed independent of userspace, but promises never to break userspace. This leads to everlasting APIs that can never get obsoleted, and on which "New and Improved" API replacements accrete, and then users get confused about which ones to use, and support effort gets divided. I suppose such is the burden of choice.
  • tremon 4y ago
    Policy should be included with the software package I don't agree with this. When you do this, any malicious package can just ship a new policy that allows the maliciousness it's planning to do. By all means, split up the mega-policy into usable app-sized chunks, but shipping the policy in the same rpm as the application is self-defeating.
• kritr 4y ago
  From my relatively basic understanding of SELinux, it seems like has a lot of powerful mechanisms for enforcing security policy, but a lackluster interface for actually showing violations or creating robust policy. Luckily, I think there’s a lot of community work coming up to make these policies easier to write and more robust. For example: https://github.com/dburgener/cascade https://github.com/dburgener/cascade Is a DSL for writing SELinux policy, and seems to aim to provide a better audit tool.
• INTPenis 4y ago
  Let me just assure everyone that it's not broken by design. Many of us use SElinux to harden systems and services on a regular. But that said, it's not user friendly either. It's definitely a skill I list on my CV. Either learn it and feel better about it, or set it to permissive mode and live with that. I agree with mindwok, SElinux defaults from distro + containers work just fine. Rarely any policy issues, and you get the isolation of containers on top of that. So I wouldn't set SElinux into permissive mode just to use containers, I'd use both. Which I currently am doing on my container host at home for example. Edit: Today's press[1] have an excellent example of a vulnerability that should be stopped by SElinux default policies. Look at NetworkManager/dispatcher.d as an example, semange fcontext -l | grep 'NetworkManager/dispatcher' and you'll see it only has the exec context on that one directory. So even if you could exploit a directory traversal and place malicious scripts in other places, it would not be allowed to execute them. 1. https://arstechnica.com/information-technology/2022/04/microsoft-finds-linux-desktop-flaw-that-gives-root-to-untrusted-users/ https://arstechnica.com/information-technology/2022/04/micro...
  • deleted 4y ago
    [deleted]
• strzibny 4y ago
  This is not a good advice. You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care. SELinux is difficult to build from scratch but there are decent tools to build your policy in an automated fashion. The advice should be this: Don't have time to deal with SELinux at the moment? Switch to permissive policy and deal with it later. I included SELinux as one big chapter in my book Deployment from Scratch rather than skipping on it.
  • elevader 4y ago
    That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.
    • strzibny 4y ago
      I say this, because it's very hard to write the policy yourself at the beginning. So let the system run for a week and then use the tools to build the policy for you. I wish it's easier to sit down and write it, but it's not atm.
      • tremon 4y ago
        How does that work? If you run selinux without a policy, you also get no type transitions and no file labels. That means that after a week, you only have a list of things your system does, with every action coupled to the init_t domain (or possibly even kernel_t), and file access targeted at unlabeled_t (unmanaged_t?). At the bare minimum, you need a base policy that already contains separate type contexts for each of your services, file contexts to apply to the service daemon binaries, and type transitions so that each service gets run in its proper context. If your daemons run in the wrong context, then immortalizing that in policy with e.g. audit2allow only deepens the swamp you're in. I don't think there's any practical way to build an selinux policy from scratch by just running your system and recording it, even if the tools allow you to do that. You can only start from your OS' reference policy or indeed write the initial base policy by hand.
• mergusserrator 4y ago
  I have ran selinux in production on rhel and centos for years, had very few problems. All packages that are maintained by red hat comes with selinux policies included, over time stuff barely changes, just some security fixes applied. In case you have trouble, just install (setroubleshoot-server) and run sealert -a /var/log/audit/audit.log and it'll inform you whats needs to be done, i.e set a sebool or generate a policy. Solves 95% of the problems.
• jdhendrickson 4y ago
  This article is a prime example of why one should think about the content of a page before accepting it's premise. I would argue that no solution in and of itself is complete. I hope someday we can get away from the idea that containerization is the complete solution. I have been a system admin for over 20 years, and it seems we still have not been able to get the concepts of defense in depth, and specifically many layers of defense on each level to soak in. I see multiple people espousing the belief (in the comments on this article at least) that containerization has solved this issue and SELinux is no longer needed. I can think of a certain chaos goose (Ian Coldwater) who has been providing plenty of reasons why it's bad to trust containers alone for years. In my personal experience SELinux has stopped attacks in their tracks when a 0 day hit, until a patch from upstream became available and is an invaluable tool for blue team in general. It is not the most intuitive of tools, but most truly powerful tools are not intuitive, that seems to be a common trade off.
  • deno 4y ago
    SELinux policy can (and does, by default, on rhel-like systems) enforce the security guarantees the container frameworks provide. This is very much an optimal scenario for SELinux when you have some macro-level policy restriction and you want to enforce it. SELinux is just not very well matched for the usual scenario of trying to graft a security policy on software and a system admin that is completely unaware of it. This means people get frustrated when an Apache server can’t read some files in some folder arbitrarily set in the config, because there never was any policy of the Apache server only being able to read files with the right security context, that was never part of the HTTPD sever documentation, it’s a default system policy called selinux-policy-targeted that originates with Fedora. Now if you run the same HTTP server in a container, you have first class concept of a volume, and the container framework is aware of that and can label files with the right context as needed; in fact with Podman it will even use MLS to prevent cross-container contamination. So IMO containers are not in any way incompatible with SELinux, they are in fact a great abstraction match and they work great together. There’s been many container escapes that were prevented by SELinux policy.
• ulzeraj 4y ago
  > Red Hat Enterprise Linux (RHEL) has some of the most accessible documentation on creating custom policies. Red Hat is the Pinterest of Google searches for Linux problems. You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.
  • cube00 4y ago
    You can get to some of the resolutions (but not all) with a free RH developer account.
    • op00to 4y ago
      This is not true. A free Red Hat developer account has access to the same resolution content as a paid account.
  • d2wa 4y ago
    Amen.
  • broodbucket 4y ago
    One thing that makes it worse is that the knowledge base resources are usually pretty good.
  • m463 4y ago
    I find the arch linux wiki and forums are very good.
  • KronisLV 4y ago
    > You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login. This gives me flashbacks to Oracle DB error documentation pages.
  • kevinmgranger 4y ago
    You don't need a subscription, but you do need an account.
• azifali 4y ago
  KubeArmor (https://github.com/kubearmor https://github.com/kubearmor) makes implementing SELinux policies easy for your host / k8s workloads. Please do checkout the project and provide your valuable feedback. All of our policies for SElinux are Auto generated using https://github.com/accuknox/discovery-engine https://github.com/accuknox/discovery-engine Writing policies by hand is nearly impossible, error prone and that is the exact problem we are trying to solve - to make SELinux and AppArmor easy for K8s workloads and now host based workloads.
• jake_morrison 4y ago
  I have built ad-tech systems which get large amounts of traffic and continuous hacking attempts/DDOS attacks. In 10 years, the servers have never been hacked. I went to the trouble of enabling SELinux and locking things down. Not sure if it was all needed, but I can't say I am unhappy I did it. After setting things up, it hasn't been a problem.
• fefe23 4y ago
  The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is like a nuclear power plant. It's good if it works as planned, but if something blows up it endangers your whole enterprise. The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. That way the radiation hopefully stays in, but history has shown that it really doesn't. Also, the wheel of history has just turned one more iteration and now admins just view the sarcophagus as something you deploy as you previously deployed the app. Who is responsible that it is air tight? Well, uh, nobody, really. You can't even blame the applications for that. Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? Library and framework functions tend to not document that properly. Obscure files like /etc/localtime, /etc/resolv.conf, /etc/ld.so.conf, /dev/zero ... how can you expect devs to build well documented and well sandboxable applications if they don't know which files their library functions will open? You may have heard of /etc/resolv.conf ... but have you heard of /etc/gai.conf? /etc/nsswitch.conf? /etc/host.conf? Wouldn't it be great if the man page of getaddrinfo mentioned those (mine only mentions gai.conf)
  • cnity 4y ago
    This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports must be provided by the process that initializes the module, so you can view imports as a kind of list of "requests for capabilities".
    • devwastaken 4y ago
      Wasm addresses memory and execution isolation from the rest of the system, however anything running in it maintains it's exploitable logic internally. If the application needs to read/write files, and someone exploits that logic, wasm won't help. The only thing that could is limiting the filesystem access in the first place and building secure software to begin with.
• pWnZMoyg 4y ago
  Seatbelts in cars are also constantly getting in my way. Why shouldn't I just cut them off?! I think the problem is, that people don't understand SELinux. And containers are not a solution, because I can exploit a vulnerability and escape the container. But if I have SELinux running, then me escaping a container would not cause any harm. There is no good tutorial for SELinux and most people don't invest the time to understand it.
• mikewarot 4y ago
  Fundamental assumptions in the SELinux model (or in my understanding of it) * Every executable has only one role in the system. * That role does not change often * Every executable can be trusted, does what it says it does, and never gets confused * Fixed access control lists, security tags, are adequate in the 21st century.
• egberts1 4y ago
  I blame Redhat squarely for not mandating a document file detailing these systems, these contexts, these users. Redhat has co-opted and has become an IBM of consulting firm: use obscured notation of an error code as a corporate revenue flow. This is not a knock against SELinux nor against the inventor (NSA) thereof. SELinux is a great privilege boundary setter at an extreme granulated level. SELinux is superior over many other system audit approaches in all area but one: that one is ease of use. Another fault is that the Buy-ins of SELinux was placed upon the group of distro/package maintainers instead of upon the developer. Another aspect on the ease of use is that There are no auto generation of SELinux policy given one executable file. No tools have attempted to adequately scan the code or object files for such its needed audit policy file. But this mapping of code to resource is often a skimped step of software development. Unlike the development of apps for a GUI/WindowsManager environment, SELinux is NOT mandated by its own library to say “thou shall use all of me” or you don’t get go to heaven (or be seen on the computer).
• hdjjhhvvhga 4y ago
  It's interesting because the author lists some very concrete problems in the way SELinux is implemented in modern distros, but their conclusion - instead of fixing these problems - is to disable SELinux completely. Will it really help the sysadmin in the long term? What we need to have is concrete feedback to the SELinux team listing the problems and suggesting the ways to solve them. I believe making the logs more verbose is probably the easiest to implement; working on high-quality and accessible documentation is another; documenting the particular policies implemented by the vendor of a particular distro is a must.
• xupybd 4y ago
  "It doesn’t help that no one wants to be told: “stop what you’re doing, spend a week to learn this other thing, make a tiny change, and then return to your real job”. They’re looking for solutions — preferably quick ones — and not a week’s worth of study." I've never had a job that would allow me to take a week to solve a production issue.
• ethical 4y ago
  Lazy ass humans. Externality - not the victim of your own decisions.
• dikei 4y ago
  I used to switch SELinux to permissive with the intention of checking and correcting the policies later, only to completely forget about it when other issues get priority. Now I just turn off SELinux and be done with it.
• _wldu 4y ago
  I agree that SELinux is largely unusable in the real-world (especially for custom apps). I've had better experience with path based MACs like tomoyo and apparmor. Firejail is also great for end users who want to safely do online banking and surf the web at random on the same machine. IMPO, this sort of isolation is the future of endpoint security. Linux has seccomp (to filter syscalls), landlock (to limit filesystem access), and other ways that devs can build these restrictions into their source code (no external MAC needed). I've lost count of the major and minor MACs that Linux offers now. OpenBSD has pledge and unveil that basically allow the same sort of thing. I would not consider docker/podman as equivalent. They are great for bundling and running apps, but they are not doing mandatory access control. So be careful if you consider docker as a replacement for SELinux... it's not the same thing at all.
  • 4khilles 4y ago
    Out of all the tools you mentioned, pledge and unveil are the most pleasant to use from a developer and operator's perspective. I'm hoping something something similar will arrive in Linux without it becoming xkcd 927.
    • throwaway82652 4y ago
      The capability to do something like that already exists in Linux, just nobody bothers to implement it at the application level because pledge and unveil are actually just more terrible hacks and are only really suitable for packages that are built into the system. In real syadmin-land, nobody wants to recompile applications just to change some security settings. Furthermore any of these things that are bolting more ACL or ACL-like restrictions onto Unix permissions are bound to eventually end up with the same problems as SELinux.
• rob_c 4y ago
  rtfm Given android uses this so much I don't get systemd getting dragged into the rant, this screams of being reluctant to follow the way the community is going
• nottorp 4y ago
  Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment. Probably because the main Linux sponsors have found that it's the only way to make money with it. SELinux... systemd... who knows what's coming next. Let's not forget ipv6, although that's not a linux specific problem. Edit: went through the discussions and it appears that all defenders of SELinux have used it in a paid professional context where it's justified to have a tight security polities. Hobbyists can't afford that time investment.
  • _notathrowaway 4y ago
    As a Desktop environment, major Linux distros have never been as well polished as they currently are. It's gotten to a point that regular people can use them without much hassle. From a sysadmin perspective,one always needed to invest time in Linux to be proficient in it, I don't see how that has changed greatly.
    • nottorp 4y ago
      s/sysadmin/paid sysadmin...
  • dylan-m 4y ago
    > Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment This is less a Linux problem, and more an Internet problem. The reason we have more security vulnerabilities now is not because software suddenly sucks and everyone is incompetent (rather, that is a universal constant): it is because software is valuable, and the internet is huge. That is why we need ipv6, but more importantly that is why we need tools that provide security in depth, which is a great deal of the complexity in Linux today. (For example, there are heaps of vulnerabilities that sound terrible, but we know their effects will be mitigated by a container, or by SELinux). Yes, as a hobbyist, one could probably grab a copy of Debian 2.2 Potato and host a website from it. Running a modern stack sounds like an investment? Keeping that afloat will need a dedicated team.
• deleted 4y ago
  [deleted]
• Mershl 4y ago
  As a Fedora user for the last 5 years I have to admit... number of times SELinux prevented an malicious access: 0, number of times SELinux bricked the Fedora desktop: 3. Changes are often released, with selinux-policy catching up a week after.
• Edynamic77 4y ago
• thomashabets2 4y ago
  The Linux security space is pretty screwed up in general. E.g. seccomp is pretty much unusable: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.html https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h... Another post of mine about how to drop privileges in Linux, and how hard it is: https://blog.habets.se/2022/03/Dropping-privileges.html https://blog.habets.se/2022/03/Dropping-privileges.html I've started writing a library for dropping privs (as if that should even be necessary), but the devil is in the details, so I've not pushed the code yet. The beginnings of it is here: https://github.com/ThomasHabets/libdropprivs https://github.com/ThomasHabets/libdropprivs
• hexo 4y ago
  Eh, what? SElinux is completely manageble and usable. I've been happily living with it for a long time. Now when I have to live with apparmor (which is exactly unmanageble) I really miss SElinux and really don't feel any secure without it. Another wave of excuses in the manner of "i don't wanna learn anything".
  • someguydave 4y ago
    “I don’t have time to learn this tech that is critical to my job” is a very common sentiment in software and systems management.
• bluedino 4y ago
  90% of the places I've worked, it's either been turned off or blindly hammered with audit2allow until SELinux shuts up. Mostly because the "admins" are too lazy to do things the right way (non-standard file paths, ports, etc) or create/change the actual required context/labels. I'll admit that like anything it can be cumbersome at first and frustrating to learn, but it is helpful.
• rubyist5eva 4y ago
  As someone who is relatively new to the Redhat ecosystem, what exactly is the purpose of SELinux? If you only run trusted applications why do you need it?
  • joshbaptiste 4y ago
    Trusted applications can be full of vulnerabilities that allow them to become malicious. SELinux and such can limit the capabilities of such trusted applications to do only what they were designed to do and not execute reverse shells or run Crypto mining software etc..
    • rubyist5eva 4y ago
      Makes sense, so it's basically an alternative to apparmor?
• tomxor 4y ago
  > After the update, I was locked out as the login screen no longer could read some files needed to authenticate my login. My last experience with SElinux (around 10 years ago) I got this exact same issue with the login manager while trying out Fedora... and after fiddling around and working around it, another issue, and another - it must be turned off, it's clearly not suitable for general purpose usage and shouldn't be enabled by default (and isn't on most distros).
• throw7 4y ago
  I gave up on selinux early on when I learned about dontaudit rules. It's nice that that amount of control is present, but don't waste my time. Disabling selinux is the first thing I do.
• lakomen 4y ago
  I've advocated for years that each program should be ran as its own user and group, isolated from the rest of the system. So let's say you run Firefox, is should run as firefox_username user and group. This way any exploit is ran with the user/group permissions, and unexploited it has no read write access outside its own user and group. Selinux is a beast but there are tools to help with determining which settings need to be applied. If you desire a truly locked down system, where you have a person or can afford a person dedicated to its security it's a good tool. Otherwise just turn it off. How likely is it your server is going to be actively attacked? Usually very unlikely. We don't count the random and always present background brute force attempts, they're just background noise.
  • dale_glass 4y ago
    You can't do that, the permissions system isn't flexible enough, and the system will fight you. Eg, pulseaudio runs as the logged in user, and your firefox won't be able to talk to it. No youtube for you. Once you figure out the flexibility needed, you're back to SELinux pretty much.
  • d2wa 4y ago
    That works for services but not apps. For apps, Flatpak tries to solve this.
• kodah 4y ago
  > Now, most sysadmins are probably not aware of SELinux nor its policy set until they can’t achieve something because it violates the policies. First, many applications come with SELinux policies. For the ones that don't, users will need to create a pipeline. When I've written custom apps I usually have a "soak test" pipeline whereby the application runs through all of its commands and configuration and we capture denials, produce a policy with audit2allow and then review the syscalls to ensure they match what we'd expect from the application. If you're logging into a box or receiving an OS image that has SELinux turned on and you don't know how to query, that bit is just a lack of knowledge. It's a very simple command and there's a finite number of modes. The wider problem is that enterprises beyond FAANG have a very tough time perceiving systems as a product or systems engineers as anything beyond advanced troubleshooters. That's why you get these huge OS bakeries that ship out a cookie cutter system that everyone must use, or else. This is all usually motivated by compliance. On top of that, while at enterprises I've noticed that they'll teach all the courses in the world about programming and databases yet there's conspicuously no classes to hone your skills as a systems engineer. The pipeline I mentioned earlier isn't magic, I came up with the idea because I understand the workflow of SELinux and I know enough about syscalls to interrogate my own code. It's kind of like the people who like to read machine code and compare it to their application but for a systems engineer. There should be classes for the kernel and userland alike. Point being, because enterprises commonly view the system as a checkbox rather than a product, or worse produce an undocumented cookie cutter product with "best practices" it harms the profession of systems engineering. Coincidentally, this is also why I mainly use the title "Software Engineer" rather than "Systems Engineer" with big corps.
• at_a_remove 4y ago
  I tried SELinux perhaps too early and found that, unless I was right on the happy path, I simply couldn't get anything to run. I recall a feeling of victory after finally being able to multihost some websites. However, I am not a great sysadmin and was pressed into service at the time. It feels good to know that I was not the only one.
  • chousuke 4y ago
    One trick that makes SELinux on RHEL much less of a bother is to always use the system-provided default paths for data and logs, and just mount additional volumes for data at these paths. The vast majority of SELinux trouble I've seen stems from people customizing things needlessly and then they need to adjust the default policies. Another common problem is not separating the OS / application binaries, configuration / data and log directories, which is just bad hygiene even without SELinux. I've seen many installs where people have just dropped their stuff in /home/ec2-user and then the whole server breaks at some point because / gets filled by a sudden burst of log entries.
• greedo 4y ago
  We've been implementing CIS hardening standards across our heterogeneous fleet of VMs for the last two years (Thank the maker for Ansible). When it came to evaluating the controls we would implement for L1, my team and our Security team negotiated which controls were appropriate for our environment. The first that I whacked was SELinux, and the Security guys couldn't understand why. In a greenfield environment where I had the time to run it in permissive mode and hopefully catch all the odd permissions it would require, maybe. A small maybe. But our environment has been around for decades, with apps that have transitioned across multiple teams, each time losing institutional knowledge. Trying to implement SELinux on theses servers would be hugely disruptive, for minimal gain. Once I was able to explain the risk/reward calculation to the Security guys, they understood. Besides, we have so many compensating controls, I have no worries about expanding the attack surface slightly.
• bedast 4y ago
  I did my RHCE bootcamp back when RHEL 5 was just released and the bootcamp course materials were not yet updated for it. The instructor worked around this pretty well. One of the earlier topics was SELinux, where he stated we would cover it for the course, but it's not on the certification exam and it's not needed past that part of the course, so we would disable it once we were done with the lesson. It's been well over a decade so I don't remember if this was day 1 or 2 of a 5 day boot camp. Disabling SELinux and implementing more manageable controls has been a default for me for quite a long time, even before my certification. My preference is for apparmor, to be honest.
• craniumslows 4y ago
  I used to be really grumpy about SELinux until I learned about audit2why and audit2how. With those two utilities SELinux is just as easy if not easier to configure than any systemd process. Every job is hard when you are using the wrong tools. Don't change your oil with pliers, and don't setenforce 0.
• mc4ndr3 4y ago
  The most direct route to security has the NIC physically removed.
• plaguepilled 4y ago
  This genuinely surprised me - I much prefer SELinux to a number of other access control systems out there (looking at you, Active Directory). It sort of does the work for you, as long as you 'train' it across a broad enough range of daily tasks. Of course, its not always appropriate to play it that way, but for personal use I've had no issues.
• goombacloud 4y ago
  The difference between SELinux policies and the systemd security settings for locking down a service is about integration and where they are maintained. The SELinux policies are not integrated well with the applications and normally the apps don't think about shipping their own SELinux policy tweaks. With systemd security settings this is much different because the app normally provides the systemd service file and the security settings are part of it and maintained by the app developers. Edit: With AppArmor it's similar and the app devs normally don't think about providing an AppArmor profile but I think it's at least a bit easier than with SELinux policies.
• darksaints 4y ago
  I just can't get over the fact that it comes from the NSA. Sure, it might be more secure, when properly configured, than without it. But it's the fucking NSA. The same agency that backdoored Dual_EC_DRBG. They're ostensibly an agency that is supposed to protect us from malicious digital threats, but they have always sacrificed that mission any time they have had the chance. I will never trust them, and I say that as a family member of someone in the NSA. SEL4-based OSes can't come fast enough.
• remyabel 4y ago
  Copy/pasting the comment I made on the blog. I have to say that I strongly disagree with the arguments made and the advice. Disabling SELinux is a terrible idea, it will increase the attack surface of your system by magnitudes. I'll be addressing arguments made (paraphrased, not direct quotes). A) "SELinux documentation is too complicated and geared towards policy makers, not end users" This is because the documentation's target demographic are system administrators using the tools to write policies. This is like complaining that a carpenter handbook aimed at professionals is too complicated for end users. You want to be looking at either the documentation for the software (Docker for example tells you how to get around permission errors with mount, or setting the appropriate bool for httpd servers) or reading the error message that tells you exactly what to do (run audit2why, file a bug report so the distro maintainers can take a look at it). B) "You should disable SELinux" Would you disable your home security system because it's too complicated to figure out? If there is a genuine bug in the policy, then it should be reported, not disable the entire thing. C) "Start from a clean slate and write your own policies" The policies are written by those who are intimately familiar with SELinux and how it operates within the context of the distro. Again as said earlier, if there's an issue, report it upstream. Trying to write your own policies, especially if you're unfamiliar with SELinux, will result in an insecure application/system. Most errors are easily solved by google or running the appropriate command. D) "It's too complicated for end users; use Docker instead" I see this argument a lot, but it makes no sense within the context of IT. The end user and system admin are two different groups of people. Why does it matter if it's too complicated for end users when the audience are other IT professionals? Docker also is NOT a replacement for SELinux. Docker is secured BY seccomp profiles, by itself it is actually significantly more insecure than people think. This shows a fundamental misunderstanding of the threat model of containers and what benefits SELinux provides.
• StillBored 4y ago
  The problem of selinux getting in the way of being able to boot/login has been going on for years. Tossing selinux=0 on the grub/kernel command line anytime the machine fails to boot is common for most people running rawhide. Which itself is a problem because relabeling can take a _long_ time if the system in question has a large filesystem. Selinux has stopped a number of active exploits, but OTOH, its probably stopped 100x as many perfectly functional systems from working. So more selective enforcement is probably the right path, and one that systemd seems to be going down as it attempts to secure services it manages, but right now welding the door shut to stop the bad guys seems like the solution we are stuck with.
• pnathan 4y ago
  > They’re looking for solutions — preferably quick ones — and not a week’s worth of study. welp, there's your problem. sophisticated tools require study and care, not a quick hack.
• temptemptemp111 4y ago
• mjevans 4y ago
  SELinux, and all of the other bolt on security model extensions, all have a parallel system problem. Fundamentally it's about adding a security definition layer that just doesn't exist in the traditional UNIX privileges model; and it isn't even the typical extension of ACLs on objects. Instead it's a whole new set of tools or patch extensions to existing tools (which may as well therefore also be custom tools) that is completely opaque and therefore impossible for anything to interact with or provide good error messages for when it does inhibit interactions. What I really dislike about SELinux and similar tools is the pivot in management. Inevitably since they're bolt-ons they also add a second policy area, no longer on the file or device but instead in some other database of inscrutable configuration files. A second and totally alien location to check when anything isn't working.
  • PaulHoule 4y ago
    Since security properties are a global aspect of a system there is something to say for having them sit separate from the rest of the system. On the other hand that means every change (potentially) has to be made twice. It's good if you want to have a committee check every change but it slows changes down accordingly. Contrast that to https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security where the reference to an object and the access to the object are tied together. On paper it's a great model but it hasn't seen a lot of real life use.
• jandrusk 4y ago
  The other thing is that not all sysadmins are security engineers and you essentially have to be one to be able to manage SELinux well. You really have to understand the security implications of incorporating policy X for application Y. Minimally, Redhat needs to come up with some better documentation around managing it along with better tools for managing policy. Like say, exporting the existing policy set before each upgrade or policy change and import them back? I'm thinking sort of what is done when a package is updated and you are prompted if you want to keep or replace your existing configs.