You are not logged in.

#1 2021-05-17 10:36:16

0BADC0DE
Member
From: Regnum Utriusque Siciliae
Registered: 2018-02-21
Posts: 267

Unsafe systemd?

I just read this article and tried the very same command:

systemd-analyze security

The results are quite impressive;

UNIT                                 EXPOSURE PREDICATE HAPPY
NetworkManager.service                    7.8 EXPOSED   ?
auditd.service                            8.8 EXPOSED   ?
avahi-daemon.service                      9.6 UNSAFE    ?
bluetooth.service                         6.9 MEDIUM    ?
bolt.service                              5.3 MEDIUM    ?
colord.service                            8.8 EXPOSED   ?
cups-browsed.service                      9.6 UNSAFE    ?
cups.service                              9.6 UNSAFE    ?
dbus.service                              9.6 UNSAFE    ?
dm-event.service                          9.5 UNSAFE    ?
docker.service                            9.6 UNSAFE    ?
emergency.service                         9.5 UNSAFE    ?
getty@tty1.service                        9.6 UNSAFE    ?
lvm2-lvmpolld.service                     9.5 UNSAFE    ?
polkit.service                            9.6 UNSAFE    ?
pritunl-client.service                    9.6 UNSAFE    ?
rescue.service                            9.5 UNSAFE    ?
rtkit-daemon.service                      7.2 MEDIUM    ?
sddm.service                              9.6 UNSAFE    ?
shadow.service                            9.6 UNSAFE    ?
sshd.service                              9.6 UNSAFE    ?
systemd-ask-password-console.service      9.4 UNSAFE    ?
systemd-ask-password-wall.service         9.4 UNSAFE    ?
systemd-journald.service                  4.3 OK        ?
systemd-logind.service                    2.6 OK        ?
systemd-networkd.service                  2.9 OK        ?
systemd-resolved.service                  2.1 OK        ?
systemd-rfkill.service                    9.4 UNSAFE    ?
systemd-timesyncd.service                 2.1 OK        ?
systemd-udevd.service                     6.7 MEDIUM    ?
thermald.service                          9.6 UNSAFE    ?
udisks2.service                           9.6 UNSAFE    ?
upower.service                            2.4 OK        ?
user@1000.service                         9.4 UNSAFE    ?
wpa_supplicant.service                    9.6 UNSAFE    ?

What do you all think about this?

Last edited by 0BADC0DE (2021-05-17 10:37:36)


Maybe Computers Will Never Become As Intelligent
As Humans. Surely They Won't Ever Become So Stupid.

Offline

#2 2021-05-17 10:52:03

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: Unsafe systemd?

The article states "We also don’t need to reach a low value for each service".

Offline

#3 2021-05-17 12:16:53

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Unsafe systemd?

And labeling the 0-10 ends of that scoring metric as "OK" and "UNSAFE" is completely arbitrary.  It could just as well be named from "TEAM-PLAYER" to "XENOPHOBIC" - all it seems to be scoring is how reliant on systemd a given service file is ... and somehow concluding a greater reliance on systemd is more safe - which is ridiculous.

EDIT: Sorry graysky, it seems I was editing while you were posting.  I toned down the absurdist angle of my post just a bit, so your fairies / unicorns reference was left hanging.

Last edited by Trilby (2021-05-17 13:05:27)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2021-05-17 12:19:52

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,595
Website

Re: Unsafe systemd?

Faries?  Unicorns?  We've hit that point with the inclusion of emojis in the assessment.  This is another example in a disturbing trend.
85-fuck.jpg


EDIT:

Trilby wrote:

EDIT: Sorry graysky, it seems I was editing while you were posting.  I toned down the absurdist angle of my post just a bit, so your fairies / unicorns reference was left hanging.

No problem, Trilby.  I think we are same page and I think taken together with some things I see in the mainstream media, and a shift in the public-facing behaviors of most large corporations, there can't be too much of an absurdist angle placed on things in this genre.

Last edited by graysky (2021-05-17 16:01:29)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#5 2021-05-17 12:24:57

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: Unsafe systemd?

0BADC0DE:
Why are you concerned with the “unsafe” output? Though the article is quite clear and tells twice, what those values mean, and manual for systemd-analyze explicitly tells what they do not mean, the only explanation I can find is misinterpretation. Which is a small tragedy of tools like systemd-analyze security. It’s more than what Allan has quoted above — you want some of them to be “unsafe”.

sytemd-analyze security estimates security exposure of the service, not whether there is anything wrong with its security. The score rates a subset of its attack surface. Understand those concepts and what are their implications, before jumping into conclusions. Using tolls like that requires comprehension of the underlying subject matter.

And if you ask, whether there are different tools, that could give a rating that is both reliable and suitable for a lay person: no. All software I heard about lies on an axis between “gives precise information, but requires expert knowledge” and “gives simple answers, but it is mostly a gimmick”, with the middle point of this axis being usually not “both” but “neither”. This is why security officers in companies are paid so much; so far they can’t be replaced with a cool, shiny app with blinking indicators.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#6 2021-05-17 13:03:31

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Unsafe systemd?

mpan wrote:

... they can’t be replaced with a cool, shiny app with blinking indicators.

And the creation of a shiny app with blinking indicators / emojis leads me to suspect the authors of that app are the opposite of the sort of valuable security people that would be hard to replace.

I had never known of this systemd-analyze tool before ... and I've already had lots of grips about systemd-analyze's more common functions (for similar reasons about how it facilitates misunderstanding).  It seems to be a questionable tool overall, and having it come from the same package that provides the init system I'm currently running is disturbing.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2021-05-17 19:59:17

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: Unsafe systemd?

Oh, c’mon! A bit of fun with emoji is hardly making it “a shiny app with blinking indicators”. What’s next? Saying that pacman is useless, because it supports colors and has ILoveCandy? ;)

systemd-analyze security is extracting information and reporting it. What’s its purpose (and what isn’t!) is very clearly stated in the manual and invoking that command with a unit name delivers a detailed breakdown of how the score was calculated. It’s neither tool’s nor its authors’ fault that someone calls it without first reading the docs, sees “UNSAFE ☹” and panics after inventing their own interpretation of that message. (╯°□°)╯︵ ┻━┻

Last edited by mpan (2021-05-17 20:00:24)


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#8 2021-05-17 20:10:15

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Unsafe systemd?

mpan wrote:

Oh, c’mon! A bit of fun with emoji is hardly making it “a shiny app with blinking indicators”. What’s next? Saying that pacman is useless, because it supports colors and has ILoveCandy? wink

It would be fun if the emoji ouput was behind a switch, maybe even undocumented as an easter egg. It doesn't belong in the default output of a tool that should be taken seriously.

... Oh, it seems I answered a question I never though to ask. The tool itself tells you that it is only there for fun and not for anything serious.

Edit: I'll have to set SYSTEMD_EMOJI=0 now, but that just replaces it with ascii smileys... https://systemd.io/ENVIRONMENT/

Last edited by progandy (2021-05-17 20:22:39)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#9 2021-05-17 20:26:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Unsafe systemd?

mpan wrote:

It’s neither tool’s nor its authors’ fault...

Yes, it is.  Having a man page telling users that a program generates misleading output and shouldn't be trusted is no justification for distributing a program that gives misleading output in the first place.

FYI, I'm now including the following in my profile, just in case:

export INIT_SYSTEM_NO_LOLCAT_LOGS=1
export I_CAN_HAS_CLARITY=999

Last edited by Trilby (2021-05-17 20:28:59)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2021-05-18 07:05:53

0BADC0DE
Member
From: Regnum Utriusque Siciliae
Registered: 2018-02-21
Posts: 267

Re: Unsafe systemd?

That wasn't meant to start any flame war. ;-)
TBH, I have been a little bit puzzled by both the article and the program output.
Forget about the emojis (I don't really like them either).
Seeing all those numbers >= 8 made me think: it's time to ask someone who maybe knows more than me:
> What do you all think about this?

What I read, among the jokes, is "nevermind, that's yet another useless reporting tool".
From the documentation (which I actually read before running) I didn't get any idea that it wasn't a serious tool:

   systemd-analyze security [UNIT...]
       This command analyzes the security and sandboxing settings of one or
       more specified service units. If at least one unit name is specified
       the security settings of the specified service units are inspected and
       a detailed analysis is shown. If no unit name is specified, all
       currently loaded, long-running service units are inspected and a terse
       table with results shown. The command checks for various
       security-related service settings, assigning each a numeric "exposure
       level" value, depending on how important a setting is. It then
       calculates an overall exposure level for the whole unit, which is an
       estimation in the range 0.0...10.0 indicating how exposed a service is
       security-wise. 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.

       Please note that many of the security and sandboxing settings
       individually can be circumvented — unless combined with others. For
       example, if a service retains the privilege to establish or undo mount
       points many of the sandboxing options can be undone by the service code
       itself. Due to that is essential that each service uses the most
       comprehensive and strict sandboxing and security settings possible. The
       tool will take into account some of these combinations and
       relationships between the settings, but not all. Also note that the
       security and sandboxing settings analyzed here only apply to the
       operations executed by the service code itself. If a service has access
       to an IPC system (such as D-Bus) it might request operations from other
       services that are not subject to the same restrictions. Any
       comprehensive security and sandboxing analysis is hence incomplete if
       the IPC access policy is not validated too.

In case this is just a silly FUD thing, then I'd prefer it to be removed from my system altogether.


Maybe Computers Will Never Become As Intelligent
As Humans. Surely They Won't Ever Become So Stupid.

Offline

#11 2021-05-18 07:08:39

0BADC0DE
Member
From: Regnum Utriusque Siciliae
Registered: 2018-02-21
Posts: 267

Re: Unsafe systemd?

mpan wrote:

0BADC0DE:
Why are you concerned with the “unsafe” output? Though the article is quite clear and tells twice, what those values mean, and manual for systemd-analyze explicitly tells what they do not mean, the only explanation I can find is misinterpretation. Which is a small tragedy of tools like systemd-analyze security. It’s more than what Allan has quoted above — you want some of them to be “unsafe”.

sytemd-analyze security estimates security exposure of the service, not whether there is anything wrong with its security. The score rates a subset of its attack surface. Understand those concepts and what are their implications, before jumping into conclusions. Using tolls like that requires comprehension of the underlying subject matter.

And if you ask, whether there are different tools, that could give a rating that is both reliable and suitable for a lay person: no. All software I heard about lies on an axis between “gives precise information, but requires expert knowledge” and “gives simple answers, but it is mostly a gimmick”, with the middle point of this axis being usually not “both” but “neither”. This is why security officers in companies are paid so much; so far they can’t be replaced with a cool, shiny app with blinking indicators.

I just asked: what do you all think about this?

Not: Oh my! How do I fix my system that's open to all those hackers?


Maybe Computers Will Never Become As Intelligent
As Humans. Surely They Won't Ever Become So Stupid.

Offline

#12 2021-05-18 07:15:09

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Unsafe systemd?

In case this is just a silly FUD thing, then I'd prefer it to be removed from my system altogether.

It does have a function. It tells you how systemd rates the settings for the service sandboxes and can show which sandboxing features are enabled for a specific service. It does not do anything else, though.
That can be useful if you plan on restricting a service (but do not rely solely on it since there are other things to be considered), but has little value if you do not want to mess with the sandboxes.

Last edited by progandy (2021-05-18 07:18:11)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#13 2021-05-18 07:16:48

0BADC0DE
Member
From: Regnum Utriusque Siciliae
Registered: 2018-02-21
Posts: 267

Re: Unsafe systemd?

progandy wrote:
In case this is just a silly FUD thing, then I'd prefer it to be removed from my system altogether.

It does have a function. It tells you how systemd rates the settings for the service sandboxes and can show which sandboxing features are enabled for a specific service. It does not do anything else, though.
That can be useful if you plan on restricting a service, but has little value if you do not want to mess with the sandboxes.

I got your idea. Thanks.


Maybe Computers Will Never Become As Intelligent
As Humans. Surely They Won't Ever Become So Stupid.

Offline

#14 2021-05-18 10:10:34

adventurer
Member
Registered: 2014-05-04
Posts: 119

Re: Unsafe systemd?

progandy wrote:
In case this is just a silly FUD thing, then I'd prefer it to be removed from my system altogether.

It does have a function. It tells you how systemd rates the settings for the service sandboxes and can show which sandboxing features are enabled for a specific service. It does not do anything else, though.
That can be useful if you plan on restricting a service (but do not rely solely on it since there are other things to be considered), but has little value if you do not want to mess with the sandboxes.

That's how I see it as well. That tool is an indication which (potentially vulnerable) services running on your system are not sandboxed and could therefore be abused by a local or even remote attacker. systemd offers comprehensive sandboxing, and there are packages with service files that do make use of this sandboxing like dnscrypt-proxy, reflector or haveged while many other packages do not.

Example: cups had several vulnerabilities in the past, some of them critical. That's probably the reason why it's confined by AppArmor in Ubuntu. It's not sandboxed by systemd, though. Executing systemd-analyze security cups gives some hints what could be done:

  NAME                                                        DESCRIPTION                                                             EXPOSURE
✗ PrivateNetwork=                                             Service has access to the host's network                                     0.5
✗ User=/DynamicUser=                                          Service runs as root user                                                    0.4
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)                Service may change UID/GID identities/capabilities                           0.3
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN                        Service has administrator privileges                                         0.3
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE                       Service has ptrace() debugging abilities                                     0.3
✗ RestrictAddressFamilies=~AF_(INET|INET6)                    Service may allocate Internet sockets                                        0.3
✗ RestrictNamespaces=~CLONE_NEWUSER                           Service may create user namespaces                                           0.3
✗ RestrictAddressFamilies=~…                                  Service may allocate exotic sockets                                          0.3
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP)           Service may change file ownership/access mode/capabilities unrestricted      0.2
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER)         Service may override UNIX file/IPC permission checks                         0.2
✗ CapabilityBoundingSet=~CAP_NET_ADMIN                        Service has network configuration privileges                                 0.2
✗ CapabilityBoundingSet=~CAP_SYS_MODULE                       Service may load kernel modules                                              0.2
✗ CapabilityBoundingSet=~CAP_SYS_RAWIO                        Service has raw I/O access                                                   0.2
✗ CapabilityBoundingSet=~CAP_SYS_TIME                         Service processes may change the system clock                                0.2
✗ DeviceAllow=                                                Service has no device ACL                                                    0.2
✗ IPAddressDeny=                                              Service does not define an IP address allow list                             0.2
✓ KeyringMode=                                                Service doesn't share key material with other services                          
✗ NoNewPrivileges=                                            Service processes may acquire new privileges                                 0.2
✓ NotifyAccess=                                               Service child processes cannot alter service state                              
✗ PrivateDevices=                                             Service potentially has access to hardware devices                           0.2
✗ PrivateMounts=                                              Service may install system mounts                                            0.2
✗ PrivateTmp=                                                 Service has access to other software's temporary files                       0.2
✗ PrivateUsers=                                               Service has access to other users                                            0.2
✗ ProtectClock=                                               Service may write to the hardware clock or system clock                      0.2
✗ ProtectControlGroups=                                       Service may modify the control group file system                             0.2
✗ ProtectHome=                                                Service has full access to home directories                                  0.2
✗ ProtectKernelLogs=                                          Service may read from or write to the kernel log ring buffer                 0.2
✗ ProtectKernelModules=                                       Service may load or read kernel modules                                      0.2
✗ ProtectKernelTunables=                                      Service may alter kernel tunables                                            0.2
✗ ProtectProc=                                                Service has full access to process tree (/proc hidepid=)                     0.2
✗ ProtectSystem=                                              Service has full access to the OS file hierarchy                             0.2
✗ RestrictAddressFamilies=~AF_PACKET                          Service may allocate packet sockets                                          0.2
✗ RestrictSUIDSGID=                                           Service may create SUID/SGID files                                           0.2
✗ SystemCallArchitectures=                                    Service may execute system calls with all ABIs                               0.2
✗ SystemCallFilter=~@clock                                    Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@debug                                    Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@module                                   Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@mount                                    Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@raw-io                                   Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@reboot                                   Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@swap                                     Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@privileged                               Service does not filter system calls                                         0.2
✗ SystemCallFilter=~@resources                                Service does not filter system calls                                         0.2
✓ AmbientCapabilities=                                        Service process does not receive ambient capabilities                           
✗ CapabilityBoundingSet=~CAP_AUDIT_*                          Service has audit subsystem access                                           0.1
✗ CapabilityBoundingSet=~CAP_KILL                             Service may send UNIX signals to arbitrary processes                         0.1
✗ CapabilityBoundingSet=~CAP_MKNOD                            Service may create device nodes                                              0.1
✗ CapabilityBoundingSet=~CAP_NET_(BIND_SERVICE|BROADCAST|RAW) Service has elevated networking privileges                                   0.1
✗ CapabilityBoundingSet=~CAP_SYSLOG                           Service has access to kernel logging                                         0.1
✗ CapabilityBoundingSet=~CAP_SYS_(NICE|RESOURCE)              Service has privileges to change resource use parameters                     0.1
✗ RestrictNamespaces=~CLONE_NEWCGROUP                         Service may create cgroup namespaces                                         0.1
✗ RestrictNamespaces=~CLONE_NEWIPC                            Service may create IPC namespaces                                            0.1
✗ RestrictNamespaces=~CLONE_NEWNET                            Service may create network namespaces                                        0.1
✗ RestrictNamespaces=~CLONE_NEWNS                             Service may create file system namespaces                                    0.1
✗ RestrictNamespaces=~CLONE_NEWPID                            Service may create process namespaces                                        0.1
✗ RestrictRealtime=                                           Service may acquire realtime scheduling                                      0.1
✗ SystemCallFilter=~@cpu-emulation                            Service does not filter system calls                                         0.1
✗ SystemCallFilter=~@obsolete                                 Service does not filter system calls                                         0.1
✗ RestrictAddressFamilies=~AF_NETLINK                         Service may allocate netlink sockets                                         0.1
✗ RootDirectory=/RootImage=                                   Service runs within the host's root directory                                0.1
  SupplementaryGroups=                                        Service runs as root, option does not matter                                    
✗ CapabilityBoundingSet=~CAP_MAC_*                            Service may adjust SMACK MAC                                                 0.1
✗ CapabilityBoundingSet=~CAP_SYS_BOOT                         Service may issue reboot()                                                   0.1
✓ Delegate=                                                   Service does not maintain its own delegated control group subtree               
✗ LockPersonality=                                            Service may change ABI personality                                           0.1
✗ MemoryDenyWriteExecute=                                     Service may create writable executable memory mappings                       0.1
  RemoveIPC=                                                  Service runs as root, option does not apply                                     
✗ RestrictNamespaces=~CLONE_NEWUTS                            Service may create hostname namespaces                                       0.1
✗ UMask=                                                      Files created by service are world-readable by default                       0.1
✗ CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE                  Service may mark files immutable                                             0.1
✗ CapabilityBoundingSet=~CAP_IPC_LOCK                         Service may lock memory into RAM                                             0.1
✗ CapabilityBoundingSet=~CAP_SYS_CHROOT                       Service may issue chroot()                                                   0.1
✗ ProtectHostname=                                            Service may change system host/domainname                                    0.1
✗ CapabilityBoundingSet=~CAP_BLOCK_SUSPEND                    Service may establish wake locks                                             0.1
✗ CapabilityBoundingSet=~CAP_LEASE                            Service may create file leases                                               0.1
✗ CapabilityBoundingSet=~CAP_SYS_PACCT                        Service may use acct()                                                       0.1
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG                   Service may issue vhangup()                                                  0.1
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM                       Service may program timers that wake up the system                           0.1
✗ RestrictAddressFamilies=~AF_UNIX                            Service may allocate local sockets                                           0.1
✗ ProcSubset=                                                 Service has full access to non-process /proc files (/proc subset=)           0.1

→ Overall exposure level for cups.service: 9.6 UNSAFE ?

This is precious info provided here. That tool is certainly not "misleading" if you know what it's meant to do. It suggests ways how to improve the security of your system by sandboxing specific services. It would be nice if were used more extensively in Arch Linux.

Last edited by adventurer (2021-05-18 10:48:35)

Offline

#15 2021-05-18 12:08:34

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Unsafe systemd?

adventurer wrote:

That tool is certainly not "misleading" ...

Yet someone who read the man page was mislead.  Don't mind inconvenient facts.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#16 2021-05-18 13:43:13

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: Unsafe systemd?

0BADC0DE wrote:

I just asked: what do you all think about this? Not: Oh my! How do I fix my system that's open to all those hackers?

How else a question, stated in this form, could be treated? In particular given the thread’s subject line?

There isn’t much to “think about” in this case. The tool collects information, reports it, done. Whether one finds it useful or nt is up to their particular needs. I believe that to an average user systemd-analyze security has little use. It’s most useful to unit developers and people wishing to help in improvement of existing units. Followed by some administrators, that may wish to better understand exposure of their systems.

To remove some confusion:

you@yourHome $ systemd-analyze security
UNIT                                 EXPOSURE PREDICATE
walls.service                             0.4 OK
front-door.service                        7.1 EXPOSED
back-door.service                         9.8 UNSAFE
roof-windows.service                      8.2 EXPOSED
other-windows.service                     9.6 UNSAFE
diy-garage-gate.service                   9.8 UNSAFE

As a developer of “diy-garage-gate” you might consider checking if you can improve it, because obviously it shouldn’t score that bad. As the user of “back-door.service”, you could notice that maybe there is some room for improvement: either you can stop keeping key in the pot on the right or work with the manufacturer on replacing weak, plastic locks. As a person tasked with securing the home you might be interested in understanding, what the risks are. Not because you want to disable “other-windows” altogether, but because you could add some security elsewhere to address their weakness. As an average home user… well, you may run the tool and panic that the windows are “unsafe”, but is that really a problem? You want them even if they are unsafe. Can any other element achieve the score of “walls”? No, not really: walls are very secure, but other features must sacrifice security to do their job.

Last edited by mpan (2021-05-18 14:00:05)


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#17 2021-05-18 14:11:55

diziet_sma
Member
From: A GSV in your solar system
Registered: 2019-08-05
Posts: 10

Re: Unsafe systemd?

Maybe relevant, a guide to some of the sandboxing measures that systemd allows: https://www.redhat.com/sysadmin/mastering-systemd

Obviously, enabling all of them for all daemons will break your system completely. Please don't do that.

Last edited by diziet_sma (2021-05-18 14:12:15)

Offline

#18 2021-05-18 16:54:04

adventurer
Member
Registered: 2014-05-04
Posts: 119

Re: Unsafe systemd?

FWIW, here's a github repository with several sandboxed services specifically for Arch Linux. The guide.conf therein is a nice introduction.

Offline

Board footer

Powered by FluxBB