Security OS.

For issues with MX that has been modified from the initial install. Example: adding packages that then cause issues.
Message
Author
imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#21 Post by imschmeg »

that particular kernel default with debian kernels, and is toggleable with the sandbox option in mx-tweak.
I never noticed that setting in MX tweak (Other->Enable Kernel sandbox). Is it new?

I tried brave recently, and it works with its own chrome sandbox now. Maybe it required kernel.unprivileged_userns_clone=1 in an earlier version?

Another kernel setting that is looked down on is kernel.unprivileged_bpf_disabled=0. There are claims that the Berkeley packet filter allows too much to run in it for it to be considered really safe for user space.

imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#22 Post by imschmeg »

@dolphin_oracle,

I have an up-to-date git version of lynis that I've been playing with.

Most of the issues lynis raises for MX are about kernel hardening and systemd services. It can't test systemd if it isn't loaded - and apparently has no other way to test services (hence perhaps a false sense of security when running sysVinit?). If systemd is loaded, lynis is primarily just doing "systemd-analyze security" as its test of services. Anyone who has systemd running can do a "systemd-analyze security" to get a similar result (with the addition of emojis like :happy: and :frown: ).

Apparently "systemd-analyze security" frowns often at Debian distros like MX (I tested Lubuntu 19.10 and Debian bullseye/sid as well as MX), mostly because these distros don't sandbox services.

My question for you or whomever is most familiar with MX's systemd shim is: if MX's systemd services are hardened using sandboxing, would this hardening apply to sysVinit as well?

User avatar
dolphin_oracle
Developer
Posts: 22033
Joined: Sun Dec 16, 2007 12:17 pm

Re: Security OS.

#23 Post by dolphin_oracle »

if doing anything thru systemd and systemctl to do the hardenening, they probably wouldn't apply on sysVinit boots.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
freemedia2018
Posts: 106
Joined: Thu Nov 21, 2019 3:56 pm

Re: Security OS.

#24 Post by freemedia2018 »

hypothetical with regards to mx/antix, though i notice that the sandboxed distros that take it seriously tend to go in one of two directions-- either towards a very software-laden server platform, or some wannabe android clone, complete with snap or flatpak.

ive played around with distros like that, and theyre not nearly as much fun as more traditional distros. im not going to use a heavily-sandboxed distro unless its trivial to turn the sandboxes off.

no devs seem to care about that, though. its one or the other. it certainly left me unimpressed with flatpak-- a good idea that i loathe the implementation of. it would slow down antix and mx a lot, to go in that direction. i dont think theyre going to do that. sandboxing certain things for security doesnt sound bad, but sandboxing all the apps isnt great-- for a fun, lightweight desktop distro.
we need a concept of antitrust violations for free software.

imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#25 Post by imschmeg »

@freemedia2018

I agree with you, mostly. I'm in favor of sandboxing (I use firejail quite a lot), but I agree that an MX respin focused on security should have the ability to tweak any hardening settings. Perhaps they are on by default in the respin, and/or there are several different profiles provided, with the ability to create more. Perhaps a MX-tool-like GUI to assist. The user should be made aware of the tradeoffs. In fact, there isn't one way to thoroughly harden a system - some hardening techniques don't mix with others. An example is mounting /proc with hidepid (which, BTW, lynis encourages) vs. using polkit. So any really good hardened respin in the MX spirit would allow users to choose which they want.

@dolphin_oracle

I don't know yet if the service hardening is local to the service, or something in particular about systemd itself, or something else entirely that fits between the two. My intuition and my hope is the latter (in the manner of bwrap, firejail, etc.). I guess I'll have to find out, somehow. MX is so atypical in its ability to boot both ways that I doubt the ability to make sandboxing of services work both ways has ever been considered, if not by the MX devs themselves. I doubt I'd find any discussion on the topic.

imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#26 Post by imschmeg »

I guess I'll have to find out, somehow.
Answer: systemd has its own sandboxer for services configured in /etc/systemd/system/<name>.service.d/security.conf files. However, the types of sandboxing it does appears very similar to what one can achieve with something like bwrap. It's the usual namespace, capabilities, seccomp, filesystem black/whitelisting sandboxing. Hence it may be possible to provide equivalent sandboxing for sysVinit using bwrap. It might even be possible to automatically translate those service security.conf files into bwrap options.

User avatar
Head_on_a_Stick
Posts: 919
Joined: Sun Mar 17, 2019 3:37 pm

Re: Security OS.

#27 Post by Head_on_a_Stick »

imschmeg wrote: Wed Apr 15, 2020 11:56 pmI don't know yet if the service hardening is local to the service, or something in particular about systemd itself, or something else entirely that fits between the two.
The service "hardening" is particular to systemd itself, the systemd-analyze man page explains this:
systemd-analyze(1) wrote:Note that this only analyzes the per-service security features systemd itself implements.
Not sure how bubblewrap could be used in a sysvinit script and anyway each service script would have to be modified individually.

Anyway, fun link for anybody who thinks GNU/Linux is secure: https://madaidans-insecurities.github.io/linux.html
mod note: Signature removed, please read the forum rules

imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#28 Post by imschmeg »

@Head_on_a_Stick

For some reason, I was associating Whonix with privacy/anonymity and Qubes with hardening/containerizing. I guess I need to update my associations. Seems like those two are likely to converge.

I really should make a Whonix VM and see what about its setup would be too annoying to deal with...

User avatar
freemedia2018
Posts: 106
Joined: Thu Nov 21, 2019 3:56 pm

Re: Security OS.

#29 Post by freemedia2018 »

imschmeg wrote: Thu Apr 16, 2020 12:07 pm I guess I need to update my associations.
yes, if you want to bow to industry propaganda. check out the page on openbsd for similar schlock: https://madaidans-insecurities.github.io/openbsd.html

some "security" people are like lawyers, theyre always looking for a way to make their next paycheck essential. im not trying to paint all security researchers this way, but there are opportunists and charlatans in every field.
OpenBSD is also missing many important security features such as CFI, SafeStack, verified boot, TPE and a lot more.
security in the industry is just like the rest of the ibm/microsoft world: its about fancy new features, marketing and one-upmanship in gimmicks. not that the gimmicks are all useless or shouldnt ever be adopted (some are useful) but security in the real world is about results.

have you heard about the raging plague of malware and security breaches on gnu/linux boxes? when you do, its generally smaller than the media says, the story is frequently tied to competitor funding, and the real story is very often not about gnu/linux but about a piece of software that also runs on windows.

the rest of the time its about people who didnt run updates on production servers or who misconfigured things. but by all means, fear the inadequacy of your gnu/linux server. theyre dropping like flies you know, gnu/linux is just a giant botnet at this point. oh, and bsd too, apparently.

one of the most important things youll ever learn about security, is that when you get away from reality and research, youll find a large supply of people selling fly hammers (for hitting flies) and orbital laser hand grenades. sandboxes also break, but they sell them like youve got swiss cheese and sandboxes fix everything. just like the security youve already got, the new shiny also breaks when you misconfigure and dont run updates. security theatre is higher profit than reasonable security. trusted boot secures profits, thats for certain. https://en.wikipedia.org/wiki/Trusted_P ... #Criticism

as to whether this post is on topic, i like to think it is. im all for a more secure distro, but more importantly i care about user freedom. its up to the user to turn on (or leave on) security features, based on their threat model. some people feel the need to have sandboxing or hardware and firmware-based security. others have different needs. a distro that tries to turn everything on at once is already assuming a lot, but if you can turn things off, thats fine.

distrowatch still considers "trusted end node security" an active distro, but lists the most recent update as 2014. sandbox all you want, youll still have vulnerabilities that need patching-- the same as now.
we need a concept of antitrust violations for free software.

imschmeg
Posts: 533
Joined: Thu Sep 12, 2019 8:32 pm

Re: Security OS.

#30 Post by imschmeg »

@freemedia2018
...when you get away from reality and research, youll find a large supply of people selling...
If you're going to quote Captain Obvious, you should at least give the dude credit! ;)

Post Reply

Return to “MX Modified”