Not exactly. In fact, the old rc.d init system is likely far easier to audit, given that it is written in shell script (edit: except for the init daemon itself, written in C) and is much shorter. The 'old' init system itself is not really that much more or less secure per se (edit: although it does have more code and a dbus interface - more room for bugs, etc.). systemd does have better isolation of the processes it manages, from the get-go, by putting them in their own cgroups but that alone doesn't really do much in itself except robustly label processes. It could be compared to the following conversation.
- Here's this bunch of workers, and here's another bunch. We've separated them into groups. They can't change groups. Only the supervisor can set your group.
- Okay. But did you do anything else?
- No.
- Do you enforce rules like "group A only needs access to these resources, so they only are allowed access to those resources"?
- No.
- Do you completely isolate each group from another?
- No.
Like SysV init, the old Arch Linux init system (which really is built on top of SysV), systemd, etc. you of course have some basic configuration of the different things (to avoid being specific) that are automatically managed (whether started on boot, at arbitrary time x, or killed when pigs suddenly learn to fly). These things (units as systemd calls them), have some sort of configuration interface (in systemd, an INI-like coonfiguration file, do support telling systemd to make use of some Linux kernel features that can increase the security of your system. Here are a few examples, pulled from systemd.exec(5):
- Device node whitelist and blacklists for that process (
DeviceAllow,DeviceDeny) - Filsystem namespacing (
ReadWriteDirectories,InaccessibleDirectories,PrivateTmp, etc.) - Denying network access (one use of
PrivateNetwork) - Denying UID changes (
NoNewPrivileges) - Filtering out specific system calls (
SystemCallFilter)
All of the above can be used to further restrict the behaviour of the processes that will be spawned by the init system. You may derive some measure of comfort from such restrictions as you see fit.
Now so far, I haven't really seen any widespread use of these, nor have I noticed any serious effort to lock down various services to the utmost level possible with systemd. That said, I am not familiar with the inner goings of each project, etc., so take my word with a grain of salt.
Arch Linux generally tries to use software from upstream sources with as little modification as possible. It is my understanding that instead of having to maintain our own system, it was just decided to use systemd as it seems that it will become the de facto (whether it is de jure is a matter for debate) standard init system. Hence, less work for the Arch Linux maintainers.
One final note, Arch Linux never used update-rc, chkconfig, or anything the like. Those are Debianisms, Fedora/RedHat/CentOS/whateverisms, etc. I'd suggest removing that from the question. systemctl is just an interface to the systemd process, like telinit for SysV, so I also suggest removing that. Arch Linux did try to hide the SysV underpinnings with its homegrown BSD-like init system though so I'd leave that. In the end, something like "Why is systemd replacing SysV/BSD init?" should be more appropriate.