Slackware 14.2 security seems over the top
 

Part of this is a plea for sanity, so, it might be TLDR, so skip to the bottom...

I've been playing around with Slackware, on and off, for a couple of decades, starting back when the linux Kernel was pre-1.0 and Slackware was using a stack of floppies.

Back then, post-install configuration was easy, but today? Not so much. I get that system and network security is important, but... there are so many LAYERS! I can't tell what's been implemented, and frankly, I'm having trouble finding out, not to mention, how to reconfigure them! It seems as if every subsystem has their own unique implementation of security. Documentation on them is pretty thin, as well.

I've had some education and training at the introductory level on system and network security and, in my opinion, what I see is breaking a few rules, here. The first one is that security should be barely noticed. It's very noticeable here. Obnoxiously so. It should sandbox a user, not get in their way. The user, once having used a admin password, shouldn't have to do so again during their session until they've logged out and returned.

The other rule is that applications should be aware of these implementations, but NOT dependant on them, especially specific ones. It shouldn't refuse to work if an implementation isn't there or disabled, like KDE and another window manager.

On a personal note, somehow, over the years, the obnoxious idea that the user should be protected from themselves has infected Slackware, along with the methods to accomplish that. Really? When did Microsoft's philosophy worm it's way in? There was a time when it was considered a learning experience for a user to accidentally destroy their system. That education was reinforced when they were forced to do a reinstall of their system a few times, and perhaps recover using back ups. I'm pretty confident that most of us have learned some essential wisdom by this method, wisdom that we would never have otherwise learned.

Then there's the software itself... are linux systems becoming java implementations? Seriously, configuration files in XML? Slackware's philosophy was to keep it simple, which is why the rc.d files are the way they are, with some compatibility to System V init designs, but, configuration files in XML? That's pretty far out into the weeds for Slackware, not to mention the lack of useable tools to edit them.

Overall, the layers of security is just overkill, most of which should be optional, to be plugged in if and when desired. For me, adding users and groups, with the shadow passwd system is more than enough, along with closing all ports and opening just the ones I use is enough. I use my system on a local private network with a decent firewall, most of which is hardwired. Wireless access is pretty well controlled too, with device specific permissions. VPN is just fine insofar as remote access when I'm not home, and really, I don't need SSH inside of VPN, inside <name your protocol fetish here>, etc to ensure security. My security needs are based on context, not Fortress mentality. Complex security implementations will only make things LESS secure, not more, because, for instance, if there IS a breech, it makes it harder to locate that single point of failure, or worse, multiple points of failure.

So, anyway... my question... and the reason for it.

What, specifically, are the security implementations? I've found polkit and consolekit, so far, and I've torn out polkit, (The window managers depending on polkit do not work anymore, so if there's a fix for that, I'd be grateful.) and any info on disabling the others, or reconfiguring the others would be nice.

I plan to use XDMCP and a headless X11 setup, so I can stop switching between systems, working from a client. I really don't care to add more network overhead than I have to, and frankly, the alternative to remote desktop access is, I find, laughable for what I want to do. XDMCP seems better for what I'm wanting to do. No plans for multimedia, just SMB, XDMCP, FTP, HTTP, and a few others, but nothing all that fancy. My install will be just for data processing, database server, as well as teaching myself a few programming languages.

So, any links, suggestions, or "Go ahead and tear out package X" would be appreciated.

Happy hacking! :)

Hello, and welcome to this forum.

I think that Patrick Volkerding policy has always been to ship what is available, as he makes no assumption on how the installed system will be used, hence allowing to accommodate a lot of use cases.

The admin who wants to restrict features, be it for security reasons or any other ones is expected to do it, not to have it already done.

But you already know that, so just a hint: review all the daemon managers in /etc/rc.d and decide which daemons you start at boot.

You don't need to remove or modify any package to do that.

I attach as an example the tuning I make for the Slint derivative of Slackware (not all daemon manager are listed).

I read your plea for sanity, and basically agree, but I'm afraid it's request denied.

Slackware is a compromise between security and 'user friendly' apps, e.g. mozilla's suite, X, libreoffice and other GUI friendly apps. It leads with KDE, for heaven's sake.

If you want security, you have no business running X

I did LFS. & HLFS (Hardened Linux From Scratch) in the early 2000s. I had a huge spam problem, but really didn't want to change email address. I ended up with

fetchmail --> --> postfix --> procmail --> mutt. Procmail sent the mail through

1. Vipul's Razor
2. Distributed Checksum ClearingHouse = DCC
3. SpamAssassin

Vipul's razor is free to non bulk linux users, and works on reports; DCC is free below a certain limit and uses frequency to catch bulk mailings; SpamAssassin had my custom rules, and hand edited scores. All in 128MB of ram plus swap, and there would have been perl & python busy as well.

The HLFS was an interesting idea: it used Pax, GR Security, but those projects fell behind, GR Security seemed dogged by infighting, and the brainy programmers gradually left the guys sitting there waiting around for updates, and got a life of their own. The Pax stuff was adopted by kernel and gcc devs in the main.

The rock HLFS perished on was gcc. It needed patches to implement some of the clever ideas (mostly mainstreamed and adopted by now) and gcc-3.x just wouldn't compile. The one remaining HLFS dev gave up and signed himself into a home for the bewildered :-P.

Are you prepared to go back to a console only distro, with qmail, tcpserver and ucspi-tcp? I don't think you want linux at all; You want linux to be BSD.

welcome to LQ.

I think you're forgetting a big part of Slackware philosophy. The KISS rule. However, I am a believer that the KISS rule mainly applies in Pat's creation of the distro, which doesn't always mean it will apply to the usage of Slackware (but many times it does). Slackware uses vanilla packages where possible, so if there are restrictions/changes in place, it is likely placed by the makers of those programs, not the distro itself.

As for typing in the "admin" password, it will save it in a single session when you use su. If you set up sudo, you can configure it to not require the password for a certain period of time (or to not require a password at all), but Slackware doesn't have sudo set up out of the box. If you use some GUI form, like KDE's setting's window, I believe it is the default of KDE to only have a password be valid for that particular usage. There might be options to change that, but I've never looked into it.

I don't know the specifics behind it, but I imagine there was going to be a lack of features in some software by not including certain "implementations" or that software might not even build without it.

I don't think Pat and team have taken any Slackware-specific precautions to ensure Slackware users are protected. I think they rely on the developers of the programs they include to use sane defaults. When the openssh developers changed it to default to not allowing root ssh logins using passwords, Slackware followed suit, because they used their default conf file without adjustment.

When you install Slackware, it still only sets up a root account. On your first login, you have to log in as root and then decide if you want to set up a second user (if you're even aware that you should do that -- Slackware doesn't prompt anything about it and only covers it in the Slackware-HOWTO on your installation media). Slackware does not set up sudo for any users and relies on the admin to make that decision. I've still managed to wipe a partition table of a drive I didn't want to with "modern linux", so it's still very much possible for users to destroy their system. We see it regularly on this forum. Overall, I'm not sure what specific things you're referring to, but I don't think many (if any) are due to Slackware's configuration, rather it's likely the defaults from the programs themselves that Slackware just packages.

Any configuration files that are in xml are due to the developers making the program choosing that method, not something Slackware decided to implement. Slackware still uses plain text files for its configuration. And it doesn't patch other software to just allow plain text configuration.

I'm still trying to figure out what the issues you're facing are. You are quite vague in your complaints. Security of my system doesn't get in my way. If I run something in KDE that needs root permissions, I get a popup that asks for my password and I type it in (I personally wouldn't want it to cache the password, because I'm not doing a ton of things that require it and I'd rather be prompted to know when a program is using root access rather than any program I launch XX amount of time after I type my password might be root or might be my normal user). Otherwise, in the console, a pretty simple su - gets me root access that continues until I either close the window or type exit.

You can try recompiling them, but the *kit might be required for them to run. I've never looked into it.

But just out of curiosity, what version of Slackware are you coming from that didn't have these? Both consolekit and polkit were added to Slackware back in the 13.1 development cycle in May of 2010. So, it's been a part of Slackware for over 7 years and 5 different Slackware versions.

My bet is that he's come from 12.2, that release was exceptional. ;)

Welcome to LQ! :)

TBH, scottjk, I read your post slowly and I didn't understand a single word of it.

Maybe try to be more specific about what, say, applications (with names) you're trying to perform which actions in?

Yup, this post was basically just a long rant with no specific details. What configuration files are in XML? In what circumstances do you have to enter your root password multiple times? What's this thing you are talking about with KDE + another window manager? In what way does Slackware prevent you from messing up your system?

Honestly, it sounds like you are just not familiar with the system and are frustrated because it is different than pre-1.0 Slackware.

I read it as well and was somewhat surprised that security was getting in his way.

I've never, ever, felt the need to rip out policykit or consolekit.

Well, he sounds a bit startled after upgrading his system directly from 3.0 to 14.2 :-)

What was exceptional about 12.2? I'm no expert, but every release I've used seemed to be equally good, of the same high standard.

I have a soft spot for 12.2 as well. I really can't remember now what made it feel so good, but it stuck in my memory as a standout release. but maybe it's just that I haven't seen eye to eye with the general direction that the upstream linux ecosystem has been heading in since and I'm looking back through rose tinted glasses.

Well said, my friend! :D

And your words will be my words too. I do not say that the other releases aren't excellent, just that 12.2 is my preferred one.

What's so great about 12.2?
I actually had 12.2 from Slamd, which was as near to slackware64 as 12.2 got. Slackware64 only came in at Slackware64-13.0. It looks like you guys transitioned from 32 to 64 bits at the same time. I had great respect for Fred Emmot but he seemed to be the only one there.

I remember it as a good release - good, but not exceptional. +1 on the disquiet about current trends. It's when they obsolete lilo, rc scripts, etc that they'll seriously annoy me.