I’m now in Fedora. I’m using the Lynis audit security tool to tighten security settings. It has flagged a number of services as being vulnerable to varying degrees, flagging them as being unsafe, medium, exposed or weak. How do I assess whether I need a particular service, and how do I disable services such as rc-local.service, where the standard command line instructions for stopping and disabling don’t seem to be working. Thank you!
1 Like
I don’t know much but
sudo systemctl status rc-local
will check if it’s active or not.
sudo systemctl disable rc-local
will disable it, and can enable if you change the command.
Some services are started by other services. In the case you need to use mask instead of disable. Just make sure whatever you are trying to disable can be safely disabled.
Thank you. Is there a guide to services in Linux? As regards services that should not be disabled, is it safe to mask them instead to reduce service exposure? I am keen to avoid a trial-and-error approach.
I don’t know of a comprehensive guide like that but it is pretty easy to find out information on a service by searching the name of it. It is also pretty easy to read the service unit and see what it is doing.
Keep in mind disabling/masking a service isn’t universally OK to disable or not OK to disable. It is directly related to how your specific circumstance. You can read a service unit(or any systemd unit) with the command systemctl cat example.service, replacing example.service with the actual name of the unit you want to read.
The line that starts with ExecStart will tell you what it does.
Masking is a more extreme form of disabling.
In plain English, disabling means “Don’t automatically start this unit”. While masking means “Don’t let this unit run under any circumstances.”
In the case of “rc-local”, it is probably OK for you to mask that if you want to. It is a compatibility service that is used for running legacy services. You probably don’t even have an /etc/rd.c/rc.local file which is what it runs.
2 Likes
In general, Fedora’s policy is that services which are exposed on the network are not started by default, unless they serve a specific need identified for that variant of Fedora — like the Cockpit management interface for Fedora Server. We also try to make servers relatively safe in their default configuration.
I’m not sure what the audit tool you are using is identifying, but I think we can help here. Why not give the list and we’ll go through them?
Please also tell us your system use case, because security is always a balance. Computers are the most secure when entirely powered off — but also less useful. So, if we know your goals, we can help you with information that will let you judge the risk and balance for each service.
4 Likes
Thank you. My aim is to take security as far as I can without losing printer access, downloading podcasts and software updates. Lynis has thrown up an extensive list, so here are the first and the ratings that it has given to them:
ModemManager.service - medium
NetworkManager.service - exposed
abrt-journal-core.service - unsafe
abrt-oops.service - unsafe
abrt-xorg.service - unsafe
Hmmm. Some of these I have no idea about why they’ve made these calls.
ModemManager.service - medium
This is useful if you have mobile broadband devices. I don’t think this is really a strong risk; you can mask it out if you want, or just remove it (sudo dnf remove ModemManager). It’ll take a few related NetworkManager subpackages with it, which should be fine — although note this includes the Bluetooth tethering functionality. Before I had a phone with mobile hotspot capability, I found that useful occasionally.
NetworkManager.service - exposed
I suppose they say this because it inherently interacts with the network, including getting SSID strings and other information from untrusted sources. Still… you probably want the network to work?
abrt-journal-core.service - unsafe
abrt-oops.service - unsafe
abrt-xorg.service - unsafe
So, what it doesn’t like here is probably this: these send crash reports over the network. The system attempts to mark and remove sensitive data, but it could be included by accident (because after a crash, the system may be in an unknown state). These reports are either anonymized or marked as protected. You can turn them off if you like, but they’re really helpful to us as a project in finding crashes that affect a lot of people (including bugs that happen a lot when there’s a million running systems, but are hard to reproduce individually). Run the “Problem Reporting” tool from your desktop GUI to see what this does and for options to configure it.
5 Likes
Thank you. Here are the next five and Lynis’ rating of each of them:
abrtd.service: [ UNSAFE ]
- accounts-daemon.service: [ UNSAFE ]
- alsa-state.service: [ UNSAFE ]
- atd.service: [ UNSAFE ]
- auditd.service: [ EXPOSED ]
At this point, I’m puzzled by their rationale.
accounts-daemon is just a service for getting and changing user account information over a dbus API. It uses policykit for authentication (in other words, you can’t just add and delete accounts without the proper privs.)
alsa-state.service just saves the state of your audio configuration.
atd is a tool for scheduling tasks. It’s kind of arcane, and has a somewhat obsolete design, but “unsafe” is overly-dramatic.
And auditd is necessary for writing kernel security messages to logs.
Honestly… I would ignore this tool entirely.
2 Likes
The Lynis security audit tool does direct users to run /usr/bin/analyze security, for each service. Running that for alsa-state.service produced an 83-line report, too long to post here.
I came across Lynis as it is covered in Donald (Donnie) Tevault’s “Mastering Linux Security and Hardening”.
So, I downloaded and ran the Lynis tool. (We actually include it in Fedora Linux already.)
In the relevant section, it’s actually just running systemd-analyze security, which is a tool built into systemd and which we ship directly. That’s where the overly-dramatic language comes from. Which sounds bad, but actually it’s not as bad as it seems in the proper context.
That context is: systemd offers security options to help “sandbox” applications — basically, limit the damage they theoretically could do if there is a vulnerability / exploit. This report analyzes whether those options are configured. From the relevant documentation (man systemd-analyze):
High exposure levels indicate very little applied
sandboxing. Low exposure levels indicate tight sandboxing and strongest
security restrictions. Note that this only analyzes the per-service
security features systemd itself implements. This means that any
additional security mechanisms applied by the service code itself are
not accounted for. The exposure level determined this way should not be
misunderstood: a high exposure level neither means that there is no
effective sandboxing applied by the service code itself, nor that the
service is actually vulnerable to remote or local attacks. High
exposure levels do indicate however that most likely the service might
benefit from additional settings applied to them.
Where I think Lynis is in the wrong here is in presenting this without the context — it seems from this report that the analysis is of the overall safety of that service… but it’s not at all.
There may be useful things Lynis can suggest, but I wouldn’t worry about this particular part of the report. The “suggestions” section at the end is a lot more useful (just skip the one about this section).
3 Likes