despite running as user root
From time to time I have the dubious pleasure of working with SLES systems. Of course, I also have to interact with yast or yast2 to configure the system and some services. You can think what you like about the philosophy of hiding the actual configuration files behind a GUI, I don’t think much of it - but that’s just a side note.
During my last excursion into the world of this enterprise distribution, I noticed a curious error. I logged into the system, changed my user context to root and started YaST2. I was greeted by the following message:
YaST2 Control Center is not running as root.
You will only see modules which do not require root privileges.
However, everything was fine with my login, as a quick check revealed:
After some googling, I then found several threads that were struggling with the same problem. Apparently, the error message occurs relatively frequently and with a variety of problems. It could be because too little RAM is available - but that wasn’t the problem for me.
In another thread a user also had the above problem, here it was due to a missing log directory /var/log/YaST2.
In my case the directory did exist, but the thread put me on the right track - obviously the error occurs when YaST2 cannot write log files. A check with df -h showed a hard drive utilisation of 100% - so of course no files could be written. After cleaning the hard drive, YaST2 was able to run normally again.
Whether in this particular case it is because no log files could be written or whether a full hard drive also causes other problems, I cannot say for sure, as no log files were written.
To summarise, it can be said that the above message appears to be relatively generic and does not necessarily indicate a lack of rights.
Or: Why security settings must always be tested
One of the first things I always change on a new server is the sshd_config, deactivating the login via SSH with password.
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM no
Normally you assume that the entries are correct and working, test the login from your own PC and are satisfied that the certificate is being used.
Cloud Init
Of course, Ubuntu is nowadays delivered with Cloud Init and since Ubuntu 20.04 this comes with a new config file called /etc/ssh/sshd_config.d/50-cloud-init.conf, which contains one single line:
PasswordAuthentication yes
Since the inclusion of the sshd_config.d directory takes place very high up in the sshd_config, this is almost always the first occurrence of the PasswordAuthentication directive and is therefore retained and the password login remains activated despite all other settings.
To completely deactivate the option of logging in with a password, the file must therefore be deleted or edited. However, as this file only fulfills one purpose, it can be deleted with a clear conscience.
- This situation clearly shows that security settings must always be tested, no matter how carefully the configuration is carried out, even from the perspective of an external context, in this case forcing the login without your own certificate.
- WTF Canonical?
Binding ports under 1024 to user processes
Normally, the Linux kernel does not allow unprivileged processes to bind to ports below 1024. Therefore, most (web) server processes run as root. From a security point of view, it is of course not ideal for the processes that handle requests from the Internet to have extensive rights, as this naturally leads directly to root rights on the entire system in the event of a hostile takeover of the process.
At this point, however, Systemd offers the possibility of allowing our service to bind to the ports by granting the corresponding process the authorization to bind to the ports below 1024 via AmbientCapabilities =CAP_NET_BIND_SERVICE. An overview of all other authorizations that can be granted can be found, for example, in the Linux man page on capabilities.
On this occasion, you can use CapabilityBoundingSet=CAP_NET_BIND_SERVICE to restrict that the service may only receive this authorization and cannot receive any other authorizations.
The unit file should then look like this:
[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
It is best to create such changes as a drop-in in a separate override file.
Translated with DeepL.com (free version)
Without changing the delivered service files
The packages of many programs contain systemd service files so that the installed services run in the background or are executed periodically. However, it sometimes happens that the files are not compatible with your own setup and need to be adapted.
For example, the unit file for the Mattermost server from the Arch repository looks like this in excerpts:
[Unit]
Description=Mattermost Chat Server
After=mysqld.service
After=postgresql.service
[Service]
Type=simple
User=mattermost
[...]
ReadWritePaths=/etc/webapps/mattermost/config.json
[...]
ProtectSystem=strict
[...]
ProtectSystem=strict ensures that the process is only allowed read and write access in the specified ReadWritePaths.
In my system, however, I have the memory for attachments sent in the chat on a mounted storage, as this data would go beyond the scope of my system SSD in the long term. As praiseworthy as this secure standard configuration is, it also brings with it the problem that Mattermost is not allowed to use the storage location under /media/store/mattermost.
Now, of course, you can simply adapt the supplied service file and adapt the directive ReadWritePath to your own requirements, but the next update can then lead to one of the following problems: Either the service file is again replaced by the one from the package or necessary changes from the upstream do not reach your own system. Especially with services that are exposed on the web, the latter is also a security risk and therefore not recommended.
Systemd-Overrides
Systemd also provides the solution to this problem: it is possible to create special override files which then simply change individual values from the original file without editing them directly.
The easiest way is to use the command systemctl edit <service>, in this example systemctl edit mattermost.service. An editor is opened, which either creates a new override file or opens one that has already been created. In addition, the entire file is commented out in the editor so that the original file can be easily viewed during editing.
### Editing /etc/systemd/system/mattermost.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Service]
ReadWritePaths=/etc/webapps/mattermost/config.json /var/mattermost /media/store/mattermost
### Edits below this comment will be discarded
### /usr/lib/systemd/system/mattermost.service
# [Unit]
# Description=Mattermost Chat Server
# After=mysqld.service
# After=postgresql.service
[...]
In this file, all values can now be adapted to the needs of your own system, but you must always pay attention to the sections.
After saving, systemctl status <service> also shows that the unit configuration has been extended by means of another file:
❯ sudo systemctl status mattermost
● mattermost.service - Mattermost Chat Server
Loaded: loaded (/usr/lib/systemd/system/mattermost.service; enabled; preset: disabled)
Drop-in: /etc/systemd/system/mattermost.service.d
└─override.conf
the file /etc/systemd/system/mattermost.service.d/override.conf was loaded as a drop-in, both files are merged and the result is used as the configuration.
Changes to the unit file can therefore be imported without further ado, as it is never changed and the necessary local adaptations are always loaded at runtime. In the case of extensive changes, a complete copy of the file can also be created using systemctl edit --full <service>, in which case future updates will of course most likely be overwritten again and again and you are again completely responsible for the status of the service configuration.
A fresh start with Hugo & new design
Hello dear readers and welcome to my redesigned blog!
As you can see, a lot has changed here. Not only have all the old posts been removed to mark a new start, but the technical basis has also been completely changed. It’s still a static site generator, but now it’s Hugo and no longer Jekyll.
This is also associated with a new design, which has been created from scratch and will probably still be adapted a little over time.
Topics
In the future there will be a colorful mixture of different topics on my blog. My main topics include:
- Development: C# and PHP are the focus, but other languages and frameworks are also conceivable - whatever is currently on my mind. Hugo itself will certainly get an entry or two.
- Linux: The use and configuration of Linux and everything that goes with it. Since I mainly work with Ubuntu, SLES and Arch in my professional and private life, most of the information will relate to these distributions, but should of course also be generally applicable.
- Server administration: Tutorials and insights into the world of server administration based on Linux and Windows.
- 3D printing: Since my brother gave me a 3D printer for my birthday, I’ve found a great new gadget that I’m sure there’s plenty to write about.
Of course, this list does not claim to be exhaustive and may change over time, depending on what I am dealing with. After all, a blog like this is also a good way of keeping a record of things you might need yourself.
Multilingualism
Technically speaking, the blog and my theme are fully designed for multilingualism, but only time will tell if I will use it.
As a generator of static pages, Hugo naturally does not offer a comment function, but to enable interaction I run an Isso comment system on my server.
