I noticed that in YaST->Security Center and Hardening->Miscellaneous Settings the help section says:
File Permissions: …] Launching SuSEconfig sets these permissions according to /etc/permissions.*. This fixes files with incorrect permissions, whether this occurred accidentally or by intruders.
However there is no command SuSEconfig and I can’t find one by searching in YaST->Software Management.
Additionally I notice that after changing file permissions to Paranoid:
# umask
0022
but what I would expect is to see 0077.
Also In Security Overview->Disable extra services the description says:
Every running service is a potential target of a security attack. Therefore it is recommended to turn off all services which are not used by the system.
These extra services are enabled:
chronyd
kbdsettings
lvm2-monitor
systemd-fsck-root
systemd-remount-fs
On another (Leap 15.0) system
…
These extra services are enabled:
apache2
apache2
ca-certificates
chronyd
systemd-networkd
apache2
kbdsettings
lvm2-monitor
nut-monitor
nut-server
php-fpm
postgresql
systemd-fsck-root
systemd-networkd
systemd-timesyncd
usbguard
My questions are:
SuSEconfig:
How to deal with it?
Is the message wrong (a bug to be reported)?
Is the umask wrong (a bug to be reported)?
Services:
Based on what are these particular services considered “extra” and “potential target of a security attack”?
Which one of them should I disable or (if I should not) how to secure them?
So, it looks like SuSEconfig is a collection of configuration files, not an executable…
Regarding umask 0022 vs 0077, looking up the table (the following Wikipedia reference can be used) the diff is between denying write vs denying all. Denying write seems to be the minimal requirement that’s necessary so that files can’t be modified or added. Denying all seems to be overkill with possible repercussions… Tightening up security beyond the minimal required involves considerable risk, with chances to cause more things (typically undesirable) to go wrong than your objective.
Typically nowadays security admins prefer to set security by policy and not individually… Because the vast number of possible settings can easily become untrackable and lead to unexpected and undesirable effects. As I described earlier in my comment about bastille, although that is based on policy, its settings were too roughly tuned to be of much use.
As for what settings should be hardened or blocked, that’s an individual decision only you can answer for your situation. Many people for example are satisfied that various layers and configurations in your default machine will do a sufficient job of securing your machine, but some people want to go that extra distance to configure redundant lockdown settings… eg For most people a hardened firewall configuration should be sufficient protections but someone else might instead want to additionally disable functionality in the kernel. Does the additional redundant setting improve security? Not if all works as expected but maybe someone wants that extra assurance to remove functionality at the lower, more basic level.
Today, Linux system security is more often set by SELinux (The traditional tool and still used by most distros) and AppArmor(the main tool used by openSUSE), The way I look at these two tools is that SELinux configures security from the bottom up, from the hardware and device drivers up through the various OSI layers. Apparmor on the other hand sets security from the top down, starting at the Application layer and working down through the OSI layers. Server type boxes which run relatively few applications probably are best configured using SELinux, but boxes that are often used by Users who run many applications and types of applications are probably best secured using AppArmor (which can be why openSUSE mainly uses Apparmor). Of course, there is overlap in my generalizations.
I recommend focusing your effort instead on studying Apparmor to secure your machine.
For both Apparmor and SElinux, both are policy based which means that people have created distributable templates, typically as you’ve discovered “Easy, Secure, Paranoid” and anything else which provides a foundation from which you can decide to customize further. I haven’t looked at the Security and Hardening Center closely, but assume that it is a simple tool for making some elementary Apparmor modifications.
A warning about any Paranoid template for any security hardening… I recommend only looking at it, and probably never to use “as is,” since such settings typically makes the machine unusable in some ways, often important.
Additional…
SuSEconfig as an executable was deprecated in 12.3,
With all its functionality and configurations moved to /etc/sysconfig,
And today in TW and LeAP some configurations continue to be migrated to other places including as systemd services.
So,
Even what now exists in the files I posted above appear to be only to support legacy functionality… inspecting the files, they look like signing hashes and a script to enable any file that might require SuSEconfig to work whether the call has the correct file naming convention or not.
Bottom line,
The Help reference described in this thread is probably inaccurate and refers to something that doesn’t work that way anymore, but to the User is still the same functionality even if now executed differently under the hood.
I am not sure I understand you here. Why do you expect that?
I assume you show this umask while being loged in as root (because of th #). But as umask is part of the process environment (and is thus inherited from the parent process) it will not be changed for that running process when it is changed elsewhere in another process. In other words, if you do an action like “changing file permissions to Paranoid”, whatever that does, even if that includes making a different umask setting somewhere, it will not change the umask of your loged in shell. And we can not see if your umask above is shown after a fresh login, or a reboot, or what ever. Thus as prove it is worthless.
From the above, you can also read that I doubt that “changing file permission to Paranoid” will do more then just that. It will probably change permissions of existing files. Why should it change the default umask for root logins? Or have I missed a more elaborate documentation about this “changing …”?
I must add that I never tried to do the things you now try.
I can also add that YaST is very good in helping you to manage your system when you know what you are doing. It will help you in doing things you want thouroughly and handle details you might forget to do (you knew how it should be done manualy with an editor and some tools, but humans tend to forget the small things, YaST will not). But it is still: you should know what you want to achieve and why.
Of course trying out and testing what happens is a great thing to do and helps in understanding. I do not want to discourage you from doing the tests, but during the years I frequent these forums, I have seen people several times painting themselves into a corner.
I did what you suggested before my last post before this and then read the contents of each file in the list.
I found that the contents don’t actually do anything except as I described, there are two types of files…
Some only contain a security hash (ie obfuscated secret)
Others are only scripts that enable a call to the location to find and use a file whether the naming convention is the older or something else.
Also, I found a reference long ago that SuSEconfig as a real executable was removed in 12.3.
I see my original post using the locate command got munged and didn’t notice when I posted…
Gotta remember this can happen when stdout is pasted into the Forums CODE tags…
Here is the corrected if someone wants to run the same command…
I don’t even know which one specifically you may have answered as you added a lot of extra info to which others replied etc. So I am missing short and clear answers to all the initial questions. (Stackoverflow style)
That’s a subjective question, so there is no possible accurate answer.
You pick for your own use. If you don’t use the service, it can be disabled or blocked. But, if you need it then I’d advise you not to disable. Instead, read up about the service and harden it.
Computers in general, and an operating system like openSUSE are used in infinite ways to do infinite things, so there is no one size fits all solution for everyone else that would be the immutable default. Instead, openSUSE provides you with ways to more easily make certain configurations you might want to do, but it’s your decision based on your situation and need that should guide what you actually do.
…