Suggestions for hardening, protecting Slackware
 

I am genuinely curious about this topic. I try my best to practice safe computing by keeping all of my systems patched, behind firewalls, and read security advisories(slackware mailing list). I scan my units with rkhunter, run as a regular user, and I do not have unnecessary services running on my units.
Some of us(me included) are not professional IT specialists, system administrators. We are hobbyists who enjoy Linux and the BSDs. I do want to learn more about protecting myself from penetration attempts, malware, and hardening my Slackware boxes.
I would appreciate it if you would please post tips, suggestions, links, advice on how to better protect our Slackware systems. I can of course google this stuff, but, I was hoping for a Slackware-centric point of view.
Thank you in advance for your thoughts on this topic. :)

That would be nice
+1

From a general point of view, a comprehensive overview is available from this sticky in the Security forum. http://www.linuxquestions.org/questi...erences-45261/

From a Slackware-centric point of view, I would say that a default Slackware install is secure OOTB. It is patently obvious that our BDFL has a conservative approach to allowing anything in Slackware that could be a potential security compromise. Examples here are PAM (famously described a long time ago as having more holes than Swiss cheese), pulseaudio (that was a vector to a root compromise at one time) and k3b (which needed to be given suid privileges by the user so that it would work).
I also note that our BDFL has been a distro maintainer longer than anyone, and I am sure that it can be safely assumed that he receives advance notification of undisclosed vulnerabilities. There is a strong track record of quickly patching potential vulnerabilities. (I know, more esoteric vulnerabilities can take longer.)

Holes in Slackware security come from services that are installed and how they are implemented. An example here is ssh, which by default allows root access and password logins. This is the way it comes from upstream, and is useful for initial setup, but once implemented can be made more secure by disabling root login and using key authentication only.

It is up to the user to become familiar with the services that they they use and to provide an acceptable level of protection. If you want to go websurfing, then I suggest you use Firefox with NoScript. It can be a pain at first, but I would not do without. Web-based attacks are your biggest threat.

I disagree. The default installation includes binary blobs, so it's as good as rooted. Even the open source non-free software is substandard from the security point of view, since we cannot expect patches to be distributed freely. Any "security hardening" would necessarily start with purging all non-free software. In practical terms, this would require an all-free repo branch, with Linux-libre kernel, and without non-free packages of any kind.

Try to get off the high horse please and answer the OP's questions properly. This is not a holy war.

Eric

I posted some basics here

http://www.linuxquestions.org/questi...ot-4175489724/

Usage of non-free software is meaningless to security. Even open source has security issues. Just because binary blobs exist doesn't mean they're any more or less vulnerable to attacks on a system.

You are implying I am treating this a "holy war", but I am not. I did not bring up any ethical or moral considerations. For me personally, they are not as important as security considerations. From the point of view of security alone, non-free software should be viewed as a non-starter. Most, if not all closed source software today is kept closed with the specific intention to conceal malicious features. Even if you disagree with this pessimistic assessment, you have to admit that it would be trivial to insert such features into the binary blobs, and they would remain undetected for a very long time. So there is a tremendous security risk factor in every binary blob, and denying it is just plain silly.

I believe, I also addressed (to some extent) the OP's questions by giving a technical description of what can be done in order to improve the security of Slackware. What I suggested (a free repo with non-free packages removed, and a Linux-libre kernel replacing the stock kernel) is an entirely viable solution. Is is easy: my anecdotal experience shows that Linux-libre "just works" with Slackware, so one only needs to point slackpkg to a free mirror. It is also a conservative solution which copies the proven security practices from other distributions such as Debian, Ubuntu, Trisquel, and many others.

Purging non-free software is only a small part of the overall "hardening" effort, but it is a vital one. What is the frigging point of doing any other hardening work when NSA can remote us at any time through a hole in our wireless driver? Why not start with the basics? Let's stop running the mystery code and the code we won't be able to patch.

Yes, but in that same aspect how do you know if a binary blob has a security flaw that does in fact exist?

Take that however you want, but purging non-free software doesn't always add up to a secure system. Hardening a system doesn't have to be at the code level like SELinux. There are other methods that work just as well without SELinux just fine. The key is using common sense, which sadly today is getting harder to come by.

And the NSA doesn't need to hack your driver to get into your system. They have other more subtle means using some of the greatest hackers and coders around. In fact they probably don't even need to get into your system at all.

Free and open-source software advocates almost always tout the security benefits of open over closed source. Not that it isn't debatable, but that's a bold statement you've just made.

That's a strawman... I don't think I've ever heard anyone say that open-source software has no security issues.

I'm only stating the obvious that removing all non-free software isn't always going to help. Obvious is obvious, so take that how you want to. All I'm stating is there are other means that are just as effective as going the SELinux route with Hardened code.

Interesting point, thanks. I am hoping for specifics, please. What other methods?

One of the best known NSA hacks wasn't anything to do with closed source code at all, rather they set out to manipulate a standard used to create random numbers in such a manor that certain bits would be known.

This little bit of NSA goodness then found it's way into closed and open source code alike.

Do a Google search on Dual_EC_DRBG and be educated on just how dangerous things can get.

FYI Even though it was spotted almost immediately, people still chose to use it.

The most common sense tactic of all... which is...

Define a proper security initiative for your systems, networks, and users with proper permissions, software programs to monitor and prevent issues, and maintain said systems with diligence and proper handling of issues when they arise while maintaining and promoting enough compatibility with software standards to allow the proper work to be done within your systems and networks with effective permissions management of resources available.

Every admin I know of was first taught this in CompTIA Security+, and was actually part of our own class project to define and give a proper way to handle dealing with any software situation regardless of OS in usage. That's basic textbook.

Slackware doesn't use SELinux, and it's fairly good on handling security issues provided you actually know what you are doing, and build the proper software around the system to maximize your methods.

It all boils down as to how well you define your defaults for your software and systems alike in terms of security, usability, userfriendliness, and restrictions through effective permissions management.

It's not going to be 100% safe, but with proper management and diligence, damage to systems can be minimized and dealt with, without yanking out enough hair to do a good Homer Simpson impression ;).

I don't wish to speak for Reaper but rather to back him up on this at least as I interpreted what he has said. He simply pointed out that just because software is Open or Closed doesn't imply it is either a security problem or not. Naturally closed software, binary blobs. are harder to identify as risks but it does eventually come out.

Besides, why worry too much about binary blobs with 8 year old security holes as in jpeg? or worse, built into Intel hardware?

Security is always a compromise between secure and convenient. It is not possible to have personal body armor that weighs an ounce and will stop a howitzer. Each person must find his comfort zone on specific systems. AlienBob's reference to "holy war" I think was to prevent the hijacking of a thread since it is not a linear let alone definitive step from closed to insecure. If you're an OSS advocate, fine, just don't spread FUD is the general idea, right? It can stand on it's own without that.

I may have been a little rash in my answer. I did not have the attention to attack you personally and I am glad you responded elegantly and with some good statements.

Actually there has been such an effort.
Kongoni Linux started out as a fork of Slackware, removing all non-free bits and getting it accepted by the FSF as a free GNU/Linux distribution in 2009: http://www.fsf.org/news/free-distrib...ngoni-trisquel
Kongoni's base was the 64-bit fork of Slamd64 actually (bluewhite64) but when an official 64-bit Slackware was released, I had some conversations with A.J. Venter and convinced him to switch from bluewhite64 to Slackware64 as his base. Unfortunately he got overworked and had to abandon his efforts. The project was taken over by someone else but the distro basically died and the web site is now an ad machine. Goes to show that a Linux distribution is hard to maintain as a one-man effort unless you have strong will and a clear goal, and are able to work relentlessly hard.

Eric