Kongoni was very nice. There was an interesting article about it in the german magazine Linux User, which made me give it a spin. I kept it on a machine for some time, and I was sad to see it go down the drain.

Download site for Kongoni if anyone is interested. http://sourceforge.net/projects/kong...?source=navbar It is a bit old but it might be of interest to someone.

samac

hardening and usability
 

I tried hardening the system but here are the disadvantages :
>when I needed to connect to the internet I had to start manually the service for Wicd.
>when I needed to print something I had to /etc/rc.d/rc.cups start
>... and also rc.pcmcia, rc.messagebus, rc.inet1, rc.bluetooth, rc.alsa, rc.acpid
Advantages:
>you control pretty much everything you need.
>in /etc/sysctl.conf you can change kernel parameters like: vm.swappiness = 10 to use less swap if you have plenty of memory.

Great philosophical discussion!
Is anyone going to offer some actual advice on hardening/securing Slackware?
John

Agreed. I am indeed enjoying the philosophical discourse. I would like to read more specific methods on how to harden, protect my favourite OS.

To harden the system as per the actual SELinux style of hardening, you'd have to rebuild the system from the ground up as an SELinux distribution. Slackware, as consequence can not be code hardened (this would require patches Slackware does not have), but it can be effectively hardened through other means such as proper security implementations.

I'd recommend reading Hardened Linux From Scratch first to understand how a code and core hardened system works and the differences in packages versus a standard Linux build and distribution goes. Hardened Gentoo works on similar principles. The HLFS book may be a bit dated, but a working system can be built from it.

To be honest, even if you had a perfected SELinux system built, without a proper security configuration, setup, and implementation of principles and parameters, it's no more secure than any other non-SELinux system out there and still vulnerable.

Reaper, why do you keep bringing up SELinux? As you stated the first time you mentioned it, Slackware doesn't use it, and so it doesn't seem particularly relevant to the OP's question.

OK through the philosophical portion of this thread I think we've established that the only way to have 100% security, short of staying powered down, is to connect to nothing, no NICs no modems no CD/DVDs, USB drives or floppies.

Maybe I'm not paranoid enough but I'm pretty happy with a hardware firewall on top of iptables software firewalls (not to the extreme of a DMZ or anything) and all services I don't regularly need turned off. I follow rkhunter's lead in configuring SSH and inetd and check hidden files and file changes.

I used to run Tripwire (and toyed with Samhain) but it never got tripped so I stop bothering. So first off are we restricting this to Desktops and maybe SOHO machines or is this wide open, encompassing multi-workstation networks etc?? and just how hardened do you guys wish to be?

A very interesting piece of history :) Of course, when I said "easy", I only meant the theoretical side of the issue. The practical difficulty of forking out, hosting and maintaining a free repo, all the while maintaining compatibility seems like a daunting task, which is why I confined my own deblobbing efforts to documentation (and, of course, keeping my own systems free).

Can I ramble for a bit? While I have nothing but respect for FSF and everything I know they do, their certification is not the holy grail of free computing. The Debian debacle taught me that a distribution can be free, technically speaking, yet fail to be certified because of the political differences. May be the "right" approach for distributions like Slackware is not to seek anyone's certification, but to provide the practical means for freedom. If there was a well-documented way to deblob the installation media, as well as a free (back and forth binary-compatible) slackpkg mirror, then the question of certification would become moot. The cost of doing something like this would arguably be a lot less than of maintaining a full-blown fork.

I brought it up as a reference example to a true Code Hardened Linux is compared to a Security Hardened implementation. The concept is what it is, and it was relevant to his question about properly securing the system using a proper security implementation.

The FSF's specification is just that, a specification. It gives a baseline into what can be done with free open source software only, but honestly it does have it's limits as to get a maximum useful system you have to mix free and non-free software.

Maybe this project can be useful

That's actually a sound project, but honestly you should read through the scripts prior to usage and learn to perform those actions without an automated script. It's very comprehensive, but not everyone will need everything it offers, and everything it offers may not be advised for all users.

Plus one action you should do isn't listed which is locking down root using a combination of enabling KDM in inittab and disabling root log in from the default of enabled to disabled, after setting up a secondary login with the wheel group.

There is no magic button, no quick fix, no automated do-it-all script that will ever replace proper administration efforts and effective policy enforcements in systems and networks along common sense tactics and proper implementations of these fore mentioned efforts.

I agree with you.
"quick fix" was not my scope when i've put the link but only a good documentation to start.

You are right Kooru. Research is always needed to start drafting an effective security policy, and not only enforcing it, but maintaining it, updating it, fine tuning it, and deploying it.

Good point. I was thinking primarily about a small home network. I've got four Slackware boxes that I administer. But, I welcome all comments about hardening and protecting Slackware. :)