
Stop Disabling SELinux: A Real-World Guide - samtoday
https://learntemail.sam.today/blog/stop-disabling-selinux:-a-real-world-guide/
======
laurent123456
> Jan 31 10:48:54 server audit[16067]: AVC avc: denied { name_connect } for
> pid=16067 comm="nginx" dest=8000 scontext=system_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket
> permissive=0

I think one reason security programs are sometime ineffective and end up being
disabled is that they give problems to developers and sysadmin but no
solutions.

I wish that rather than messages like "doesn't work - too bad", these programs
would output a solution as well, such as "consider setting
`httpd_can_network_connect` to `true` to allow it".

In some cases it might be tricky to propose a solution, in which case even a
link to the doc would be useful like "check
[http://example.com/doc#456](http://example.com/doc#456) for more
information". That would go a long way towards making security software issues
less of a pain for those who aren't expert in the topic.

~~~
obelix150
"audit2allow -a" or "audit2why" will tell you what the reason for a denial is
and potentially how to fix it. Pretty sure it will tell you to run setsebool
to allow httpd_can_network_connect in this instance.

~~~
snuxoll
audit2allow is the single greatest tool I've ever used for dealing with
SELinux, people need to hear it's name sung from the mountains.

I actually write SELinux policies for software I develop, first thing I do is
put them in the most restrictive context imaginable with no permissions, set
SELinux in permissive mode and run the application through it's paces, at the
end run audit2allow and there's 90% of the work done for you outside of
defining fcontext's.

~~~
blockoperation
It must be used with care though, otherwise you'll end up with so many holes
in your policy that you defeat whole point of using SELinux in the first
place. Definitely don't use the output directly.

~~~
snuxoll
Certainly not, but it's a great first step.

------
cessor
I ran a centos server for a while (ran= not my responsibility any longer) with
SE Linux and a tomcat portal app, as well as other, custom web apps (ruby on
rails with a mail queue and mysql backend, etc). I always left it in
permissive, because I couldn't figure out how to properly configure it.

I tried understanding the principles behind it and configuring the different
exceptions for several classes, but often, this didn't work (e.g. I had used
wrong class, or enabled exceptions that were still blocked). The users of the
rails app kept calling, asking me why this or that feature wouldn't work. It
was impossible for me to configure all exceptions - to me this was not
surprising, given the complexity of the software that we had installed. I
simply deemed the apps too complex and too "feature rich" to configure all
SELinux exceptions manually.

I then understood that there is a different way: To set it to permissive, keep
it running for a while and then generate an installable permissions profile,
allowing all occured violations as some kind of permissable exceptions.

This made sense to me, however it required downloading some dubious python
script, that would create some dubious binary file. I got this to work, but
then again, this or that feature was blocked. I finally kept it running on
permissive. This is my individual story. The article makes it look as if it
was really simple to configure it (When I started with SE I tried similar
moves but never got it to work).

So, is it just me, or might it be that SELinux just has a major usability
issue?

~~~
snuxoll
Why aren't you testing things with SELinux before you deploy them to
production? Also, if you constantly need to alter your policy it sounds more
like your application is poorly-behaved, not that SELinux is your problem.

audit2allow is a great tool for simplifying the development of SELinux
policies, but it doesn't remove some hand-crafted modifications to policies,
especially in regards to file contexts (fcontext).

~~~
justanotherbody
Keep in mind there are a LOT of apps deployed on systems with SELinux with
few, if any, tests

Further, the divide between ops and developers in many cases leaves this as an
unsolvable problem - it's not the dev's job to do sysadmin, and ops lacks the
expertise (or time) to comprehensively analyze the code base

You're right that this makes the app poorly behaved, but if that can't be
addressed then... permissive mode it is

~~~
snuxoll
Everyone keeps telling sysadmins they need to be able to write code, how about
developers start learning more about how their applications are deployed.

I wear both hats, and then some more on top of that - if someone on my team is
doing something that will make deployment and security difficult I make sure
to nip it in the bud during testing.

------
simias
The problem with SELinux is that it's disabled by default on many distros. If
you follow guides online that weren't written for a SELinux-enabled Linux
install then it won't work.

To make matters worse SELinux-related errors can be pretty arcane if you don't
know what's going on. I'm usually a FreeBSD guy but I had to setup a CentOS 7
box a little while ago. I thought I was going insane when I couldn't get nginx
to connect to a unix domain socket. After a hour of hair pulling and non-
conclusive googling I finally understood that it was SELinux related.

I will admit that after that I simply disabled SELinux and never looked back.
The benefits didn't seem worth the hassle to me.

If I want additional security and sandboxing I'd sooner use something like
FreeBSD/solaris jails. It's not exactly the same thing of course but I find
the mental model a lot simpler ("a machine within a machine") than SELinux's
complicated and (IMO) hard-to-debug rules.

~~~
lima
The fix for that would have been:

    
    
        setsebool httpd_can_network_connect=1
    

audit2allow even tells you right away which booleans apply:

    
    
        tail /var/log/audit.log | audit2allow

~~~
simias
Thank you for that, that might be helpful in the future!

But it kinds of demonstrate my problem with SELinux: when I had my unix socket
issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg,
etc... but I couldn't figure out what wasn't working right. All the
permissions looked fine and yet I kept getting cryptic failures.

With something like a jail, once it's set up I can just use my un*x admin
experience without having to learn a brand new OS-specific (if not
distribution-specific) set of tools.

~~~
lima
Well, you get that with any security technology and it's just one of many
things to be aware of when you use another distribution.

~~~
clarry
_Well, you get that with any security technology_

That's just not true. There is plenty of security technology that doesn't
require you to figure out new tools. There is security technology that doesn't
have tools at all and there is nothing to figure out. The program either works
correctly or it's buggy and there is no knob to make a buggy program correct.

And then there is security technology that is more or less understandable with
knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't
introduce new fancy tools. A program doing something it promised not to do
will get killed with abort trap (which can, admittedly, be a little cryptic if
you don't know pledge does that). In addition, the name of the binary, the
pid, and the offending syscall is printed in dmesg. Perhaps it would be better
still if the dmesg line included the word "pledge" as a hint & guarantee that
you'd get relevant results on Google.

~~~
lima
Well, "security technology" in the context of mandatory access control
frameworks. Bad choice of words.

My point is that any ACL framework will require configuration, be it SELinux,
AppArmor, Tomoyo, or pledge.

If you want to use pledge to confine applications that don't use the pledge
API, it will get complicated, too (admittedly not quite as complicated as
SELinux, but still).

SELinux writes denials to the audit log and you get plenty of relevant
results.

pledge is obviously much more sane than SELinux, but someone has to write a
policy no matter what technology is used.

------
daenney
The Gentoo wiki has an extensive and really good set of tutorials[0] on
SELinux. It took me some time to get through those but it greatly increased my
ability to work with SELinux. It does a good job of explaining the concepts
themselves and help build some familiarity with the CLI utilities and
especially the debugging capabilities.

[0]:
[https://wiki.gentoo.org/wiki/SELinux](https://wiki.gentoo.org/wiki/SELinux)

------
technofiend
Frankly I found SELinux a little inscrutable and not worth the trouble of
learning since I didn't use it at work, despite otherwise being someone who is
up for self-education on anything new and interesting.

However the Redhat certified admin and engineer classes cover it with enough
practical examples to make any SA functional with the tool. And as a former
consultant learning anything people _consider_ difficult whether or not it
really is can be profitable. :-)

------
eikenberry
I never disable SELinux... but that is because it was never enabled. I use
Debian and SELinux has never been on by default and if it were good enough it
would have been. There is a reason it was never enabled.

~~~
tremon
True, there is a reason, but the reason is lack of focus among the developers,
not whether it's good enough. Selinux has been maintained for years by just
one developer (Russell Coker), and that just isn't enough to maintain up-to-
date policy files for all 20,000 Debian packages. Lately Laurent Bigonville
has stepped in to share some of the load, but I have never seen more than 3
people in Debian's selinux team.

It would take an explicit release goal to enable selinux for Debian, and part
of that release goal would be requiring package maintainers to help with
maintaining the policy files for their packages.

~~~
dredmorbius
The facts that:

1\. The package has only one maintainer.

2\. The package requires heavy maintainer intervention.

3\. Shit's on fire, yo.

All suggest that whatever it is that SELinux is meant to be a solution to,
it's not a particularly good, or compelling, solution.

Stuff that needs custom wiring for every single package (and at last count
Debian was in the 50-60k packages range, though a fair number of those are
extra, source, and documentation packages) suggests ... issues.

~~~
tremon
_whatever it is that SELinux is meant to be a solution to, it 's not a
particularly good, or compelling, solution._

Well, yes. Enforcing that surgeons wash their hands and wear protective
clothing in the OR also isn't a compelling solution to surgeons, because it
limits their response time. But the behaviour is forced upon them anyway (by
either employment policy or insurance), because it is better for the patient.
Selinux does the same thing: it requires security-aware behaviour from
developers (by requiring the package to enumerate its expected behaviour
beforehand) not out of convenience for the developer, but to improve the
security for the user.

And that explains why Debian does not use it while Red Hat does: Red Hat can
enforce selinux compliance by company policy, while Debian has to rely on
every individual developer's judgement about the effort/benefit ratio. And
just as with hygiene in medicine, the effort is internal while the benefit is
external. That's why I said it would take a release goal (or general
resolution) to effect that change in Debian.

Protective rules are not meant to be a compelling solution for those who have
to abide by it. I don't see why we should expect selinux to be any different.

~~~
dozzie
> And that explains why Debian does not use it while Red Hat does: Red Hat can
> enforce selinux compliance by company policy, while Debian has to rely on
> every individual developer's judgement about the effort/benefit ratio.

There's also this little thing that Debian has an order of magnitude more
tools and programs included in its official repository, and two or three
orders more packages. This alone pretty much explains why Debian cannot just
put SELinux into use, while Red Hat somewhat can.

~~~
slrz
Fedora has a repository of comparable size and still manages to ship with
SELinux enabled.

------
sergioocon
I've been using SELinux in my Fedora the last 3 years, always on enforcing
mode.

No major problems, just minor policy changes needed that the helper was
already suggesting and that were easily fixed.

With the only exception that SELinux does not like my iPhone.

~~~
onli
I just fixed a bizarre problem on Fedora by disabling SE. By the way, the user
is using a PC I configured with used hardware, partly from me. It's supposed
to be a just-works system, meaning that it runs Fedora and I did no special
configuration at all.

That was the error description I got: "When starting the network does not
work. I have to do a lot of things to make it work." Later I got more infos:
"It says there are 7 errors. If I let it fix it it has to restart and then
works".

It turns out that these 7 errors are all SE-Linux-Errors. Something about
/etc/resolv.conf not being readable. The error helper suggests to fix it for
now and also some command to fix it permanently, those commands fail and do
nothing. So of course I just deactivated that SE-bullshit.

Really, fucking vanilla Fedora on a mainstream Gnome3 desktop. What the hell
are they thinking?

~~~
lima
If you'd post the actual errors, I'm sure we could help you with that.

~~~
onli
You mean the actual error message? Sorry, it's already solved now and I didn't
write it down. It was in Spanish, so I also don't remember how it was worded.
But its content is correctly described above: Unable to open /etc/resolv.conf.

And btw, that is exactly what I don't want. I do report errors, I solve bugs.
But I don't want to debug SE-errors, which just because of its paranoia makes
perfectly normal usage impossible, so far that distros that enable SEL spit
out errormessages immediately after installation.

I don't see its purpose anyway.

~~~
seanp2k2
The main value in SELinux is to protect apps against things they should never
be allowed to do (like your web app reading /etc/shadow or notepad listening
for network connections) so that even if they get hit with a 0day, they're
still not really vulnerable because the SEL stuff blocks all the bad things
they could do. It really truly works in practice to prevent a bunch of bad
stuff. In reality though, most people just disable it because it's a pain to
learn and deal with.

~~~
onli
I know. But thanks for the answer. It is not what I meant, but it responds to
what I wrote.

A security-solution that makes normal use impossible is not a solution.
Security solutions never work if they make usability worse. SELinux goes
farther, it also makes functionality worse till impossible. That is what I
meant when I wrote that I don't see the point of it.

Something like that can be a good solution if you are manually hardening a
specific process. As a general security solution it is completely unfit. I
don't see the point of pushing it for that. Fedora should never have activated
it.

------
Ensorceled
At my last gig we enabled SELinux as part of our PCI security procedures, I
highly recommend it but be aware that there is a fairly big ramp up.

It pretty much doubles the effort for most sysadmin tasks, even simple things
like tweaking a server setting become multi-step processes.

In my case, it was part of the reason I switched the team from DevOps only and
brought in a real sysadmin.

~~~
e12e
Eh, "real" devops is having "real" developers and "real" sysadmins working in
multi-displinary teams? Sounds like you went from NoOps (lolops?) to DevOps
:-)

~~~
Ensorceled
True, I should have put "DevOps" in quotes :-)

------
neurostimulant
I think one of the reason why people disable AppArmor/SELinux is due to bad
experience spending hours trying to figure out why their service fails to run
after a config update only to realize it was blocked by AppArmor/SELinux.
They'll just disable it and says "good riddance".

If you're running a headless server and can't figure out why your service
suddenly can't start after a seemingly simple configuration updates (changing
port, changing data directory path, etc), be sure to check AppArmor (Ubuntu)
or SELinux (Red Hat distros) logs first.

------
devnonymous
Just my experience: Ever since it came enabled by default on fedora I've been
using it in Permissive mode ie: don't enforce but notify about violations.
IIRC, since the last couple of releases I've seen maybe a couple or so
notifications, so the default set of rules out of the box on fedora are
definitely much better now than they used to be.

I might just turn it to enforcing mode.

~~~
proaralyst
I've been using Fedora since 21 (I think) and I've never switched out of
enforcing. Occasionally you get notified that Chrome has violated something
but the notification explains how to allow it if you want to.

I'd really recommend it, it doesn't seem to impact the system usability in any
way.

------
bandrami
Some distro (Mandrake? Debian? This was a while ago) had a bad default SELinux
setup _for years_ that introduced a subtle vulnerability that wasn't there in
boxes that had SELinux disabled.

Knobs that can be tweaked can be tweaked wrong, and wrongly-tweaked knobs are
security problems. Frankly I don't even like ACLs and capabilities for that
exact reason: it's no longer immediately obvious what the actual permissions
in a situation are ("let's see, the daemon is running in an unprivileged
account, but it has CAP_SYS_ADMIN set, and this file is inheriting its ACLs
from the parent dir..."). Making it more difficult to reason about security is
generally a Bad Thing, and not worth whatever features that difficulty brings
with it.

~~~
bkor
Practically there's been many examples where SELinux restricted a security
vulnerability. I think SELinux is way too complicated. Needing to know exact
commands to turn error messages into something understandable is bizarre.

That said, SELinux determines what is allowed. Having it introduce an
additional vulnerability/permission just due to configuration is really odd.

I tried searching for your example, but can only find security bugs, not
configuration issues.

~~~
bandrami
Turns out I was thinking PAX/Grsecurity back in 2005. Same principle, though:
more knobs to turn = more knobs to turn wrong.

------
tokenizerrr
I want to, but this article was not enough. Say I have my own binary running
as a service, and it has to do these things. What do I do? This article seems
to be geared specifically towards nginx/a httpd.

I should probably just read the manpages.

~~~
jfindley
Unfortunately, this is an area that could use some work. Tools for writing new
policies are a long way away from what they could/should be. If you need
something to work with SELinux that doesn't come with a policy you have
essentially three options, in order of preference:

1) Develop a new policy from scratch. This is fairly hard, and the tools, such
as they are[0], are not great. There's a couple of good resources out there,
including [1] which has some good examples, and Dan Walsh's blog [2].

2) Use audit2allow to generate a policy semi-automatically. The resultant
policy won't be very clean, and will almost certainly be more permissive than
it needs to be, but if 1) is too much work (and I wouldn't blame you for
this), then this is the next best thing.

3) Run your binary in the unconfined domain (do something like chcon -t
unconfined_exec_t /usr/local/bin/foo), but leave the rest of the system
enforcing. This will mean your binary itself is able to do anything, but the
rest of the system is still protected.

Oh, and if you haven't read it before, you should definitely check out
[3](pdf).

0:
[http://oss.tresys.com/archive/slide.php](http://oss.tresys.com/archive/slide.php)
1:
[https://github.com/TresysTechnology/refpolicy/blob/master/po...](https://github.com/TresysTechnology/refpolicy/blob/master/policy/modules/system/application.if)
2: [http://danwalsh.livejournal.com/](http://danwalsh.livejournal.com/) 3:
[https://people.redhat.com/duffy/selinux/selinux-coloring-
boo...](https://people.redhat.com/duffy/selinux/selinux-coloring-
book_A4-Stapled.pdf)

~~~
tokenizerrr
Thanks, all of those links are very informative. Shame that it seems like
quite a lot of work still to set up for my own applications.

~~~
snuxoll
audit2allow takes care of 90% of the work for you, the rest is removing
extraneous permissions and defining file context's (fcontext) which is pretty
simple.

Really, it's as simple as this, I swear:

1\. Write an empty policy for your application, defining a type for your
binary (myapp_exec_t) with no permissions at all. Label your binary with this
using chcon.

2\. Set SELinux in permissive mode, run your application through it's paces.

3\. Run audit2allow to get a decent policy to start with

4\. Figure out where your application stores data on disk, if at all. Create
another type (myapp_t) and label those directories with it (you shouldn't be
writing outside of these directories by default, if you allow it to be changed
in a config file the administrator can label new directories with semanage),
then grant your application access to this type. Also make sure the installed
path of your binary is labeled with your myapp_exec_t type.

5\. Clean up the messy policy that audit2allow created if so desired, it's
likely more permissive than necessary and not overly pretty. This will become
easier as you work with SELinux policies more.

6\. You're done

This will be time consuming the first couple times you do it, but you'll get
quicker at it over time like anything else.

------
baldfat
OpenSUSE as well as Arch, Debian and Ubuntu uses apparmor and I never had a
problem where I had to disable it.

apparmor is less complex but SELinux can be fine tuned at the cost of pulling
out your hair with what security gain? The BIG ISSUE is the KERNEL SELinux and
apparmor have the same policy with Linux Kernel aka both of them can be
bypassed and a hacker can just focus on the Kernel.

~~~
kiwijamo
Does Debian use AppArmor? Never run into it and I use Debian regularly. I read
elsewhere Ubuntu uses it but I suspect Debian doesn't.

~~~
baldfat
Once again AppArmor is great for being simple it has been a mandatory part of
Debian's framework since Wheezy 2013.

------
njharman
Hours I've spent dealing with security breeches (on Linux) - a few, false
alarms.

Hours I've spent dicking with selinux - too many before disabling it.

OTOH I've been admining *nix from before Linux existed.

------
yousry
Why should I not use GRSecurity?

Comparison matrix;

[https://grsecurity.net/compare.php](https://grsecurity.net/compare.php)

~~~
chrisbolt
Why should I trust a page with checkboxes under GRsecurity and X's under
everything else?

~~~
Avshalom
It's trustworthy, it's just misleading. GRsecurity is a whole suite of
security related patches/modules that SELinux/Apparmor don't do and have never
claimed to do because they're 'just' about MAC.

------
sandGorgon
some things need a change to not NEED selinux. For example, lots of password
files and certificates should not be stored in directories and files (and
mucked about in selinux). They are better off in the Gnome-keyring (which is
severely underutilized)

for example - networkmanager-openvpn. Openvpn certfiles are usually shared by
vpn providers and then when trying to load them, throws selinux errors.

Here's the bounty to fix it -
[https://www.bountysource.com/issues/41582244-doesn-t-copy-
re...](https://www.bountysource.com/issues/41582244-doesn-t-copy-referenced-
certitifcate)

~~~
EdiX
Gnome-keyring is a poorly documented, DE specific solution that will rope in
libdbus abnd a dbus service as dependencies. There are few circumstances where
gnome-keyring is the answer.

~~~
bkor
> Gnome-keyring is a poorly documented, DE specific solution

It hasn't been GNOME-specific for around 5 years.

Quoting
[https://wiki.gnome.org/Projects/Libsecret](https://wiki.gnome.org/Projects/Libsecret):

"libsecret is a library for storing and retrieving passwords and other
secrets. It communicates with the "Secret Service" using DBus. gnome-keyring
and ksecretservice are both implementations of a Secret Service.

libsecret replaces libgnome-keyring."

~~~
EdiX
I didn't say gnome specific, I said DE specific. There's only two
implementations and both of them can only be trusted to work correctly if you
run them in combination with their respective desktop environment.

------
fest
selinux is enabled by default on Android (since 5.0 or so) and if I recall
correctly, is required for google to certify an Android device.

IMO it definitely reduces privilege escalation attacks there. I wonder if
Apple uses similar MAC system on iOS?

Also, it is usually transparent for user app developers but can cause a bit of
headache for platform/system devs.

I just literally spent a day on an issue where android system service checks
selinux permission but does not audit the denial (= no error in logs) under
certain conditions. That was not a problem with selinux per se, but disabling
selinux would "solve" the problem.

------
patrickg_zill
The problem is that I never had local users that might be malicious or that
were prone to be hacked.

The attacks for servers tend to be over the network and there are many
different ways to mitigate those.

~~~
lima
Actually, the default Red Hat SELinux is exactly for preventing network
vulnerabilities. Local users are unconfined.

Example: your web application allows remote code execution. Even the default
rules prevents most access (spawning a shell etc.) and generate lots of
alerts.

------
throw7
Not one mention of dontaudit rules. The day I found out about them (years ago
when I tried to use selinux in the "real world"), I said nope.

------
msimpson
If system administration was carpentry, SELinux would be the glue. And
sometimes, it's just easier to use screws.

~~~
georgyo
I like your analogy, but I would flip the metaphors. Gluing is fast and easy,
using screws requires time and effort.

~~~
msimpson
Consider maintenance of the object in question, now it's a task of removing
glue versus screws.

------
rascul
I'll stop disabling selinux when I have a problem that it solves.

------
devdoomari
how does app armor compare to selinux?

------
hobarrera
So, this is a guide about how you can configure a broken out-of-the-box
security framework, trying to convince me to enable it?

Thanks, but I'd rather start from something that works, and build adding
security from there, not viceversa.

------
adakbar
It brought shame everytime I need to config new production server, first thing
I did was change to pemissive mode

------
Proven
I call BS. I have 0 use for it. I wouldn't disable it as a matter of best
practice, but it's too annoying.

------
hadfgdasf
I will continue to disable SELinux, and no number of arcane articles about how
EASY it is will convince me otherwise.

Stick that in your pipe and smoke it.

~~~
saywatnow
Your loss. I agree that the way it's sold as "EASY" (caps appropriate) is a
bit ridiculous, but SELinux does add a stong layer of protection from
vulnerabilities in one service leading to total server pwnage. Ignore the
rhetoric and try to work with it - the peace of mind pays off.

~~~
sgt
What if an app does something during runtime that you had not catered for?
This effectively means potential downtime for the app while your admins are
trying to figure out why the app is failing.

I agree SELinux adds something to the table, but the article shows two
examples (httpd_sys_content_t and httpd_can_network_connect). Let's assume
there is a third httpd_can_foo_bar that is required down the line. And then a
http_can_bar_quux a few hours after that. All in all this can be a bit risky.
Perhaps if there was an easier way to administer SELinux?

~~~
corney91
1\. Functionality that'll be used should be tested before going into
production.

2\. Using something like setroubleshoot will make sure any SELinux denials
appear in the syslog so should be simple to diagnose, and sealert will tell
you likely solutions. Personally I think that's how distros should be shipping
SELinux, not sure what the downsides are.

Note, I'm mainly talking about servers here. Personal computers always seem to
have messily-packaged applications running, so I can see why people get
annoyed with SELinux there (although I've never had a problem with Fedora,
yet...)

------
throw2016
No Thanks! Given the never ending list of revelations Redhat's deep ties to
the US security industry and the NSA are problematic. Why should anyone not
already a part of the government security industry trust selinux?

By not coming out openly and explicitly criticizing the US security services
for their anti constitutional and blatant authoritarianism Redhat has
demonstrated which side it is on. It has no qualms enabling and supporting
this behavior and is not a principled member of the free software movement.
Something for which it has yet to be held to account.

Given the movement against Trump is exactly against this kind of
authoritarianism the lack of scrutiny of tech companies like Redhat, Palantir
and others is hypocritical. By not speaking out you are supporting these
actions.

The fact that it is an absolute pain to configure and representative of a user
hostile software model makes it that much more easy to avoid even for those
with more practical considerations.

~~~
lima
SELinux is the least likely part of the kernel to contain a NSA backdoor :-)

~~~
digler999
there was that one program..."system-something"....system-A ? was it ? or
system-B ? or , hmm. "system-C". something like that, just... _might_ have a
vulnerability or two ?

~~~
lima
Or literally any other part of the stack.

