What are the security implications of systemd compared to systemv init?
(mostly) people don't inject vulnerabilities deliberately, they occur by accident. As the volume of code increases, the number of defects increases. But its not just size - the number of bugs increases with the complexity of the code and it increases faster than linearly. So more code is bad news for security.
The attack surface of systemd is massively larger than initd - the default configuration has multiple interfaces.
A big annoyance for me is the design philosophy; the intention is that systemd provides a more unified way for distributors to integrate services. But this means removing control over the system from syste admins (over and above the impact of replacing a complex but well understood eco-system). It deliberately makes it hard or impossible to achieve thing which could be done with initd (note that there are many options for service managers running under initd - djb daemontools, upstart, initng, rund, procd, openrc.... Most of which solve the paralellization / dependency problems that limit the sysv rc init system).
A lot of the logic of the start up of a unix system is implemented in shell scripts. This makes it much easier to not only reverse engineer the operation but also to instrument it and extend the capabilities. Systemd moves more logic into binaries and relies more on a complex and poorly documented configuration.
The combination of deliberately reducing the level of control by the system administrator and failing to support the system administrator in their task makes it more difficult for them to do their job - which encompasses assuring the security of the system.
A further consequence of all this complexity in PID 1 means that you should have to reboot your system a lot more frequently. In addition to the impact on availability this also means moving your system through a series of interim states - which can temporarily expose vulnerabilities which are difficult to detect on a homeostatic system. Using daemon-reexec to work around this brings a new set of problems.
The benevolent-dictator-for-life model seems to work well for the linux kernel, but that is not how the rest of the open source industry operates. Indeed it is perhaps the exception which proves the rule - that open source works because nobody is in charge, not despite nobody being in charge. Systemd assumes control over a lot of the functionality in a linux system, yet it operates as a relatively small community. And as per the pwnie award it appears to be somewhat inward looking: there are not a lot of eyeballs on the code: nobody is listening when concerns are raised about the code.
Systemd is actually a collection of several parts, and for a comparison to make sense, you have to compare the parts that actually correspond to each other.
Let's first look at SysV init: This is a very small program that is run as the first process after boot that does some very basic setup, then reads a configuration file (/etc/inittab) and starts one or more programs configured therein, optionally restarting them when they exit. It also opens some communication channels (/dev/initctl, signal handlers) that make it possible to change the current runlevel, a change of which will result in some other programs to be run, again as configured in /etc/inittab.
And that's it. Obviously, this doesn't have a large attack surface, simply because it does almost nothing. On the flipside, everything else that's required for actually managing a typical system is delegated to external programs: how to start and stop a specific service (e.g. web server, database, network...), dependencies between services (i.e. start the database first, only then the web server), more complex monitoring (watchdog functionality), privilege dropping and sandboxing, on-demand service activation (e.g. inetd), mounting filesystems, ... Systemd integrates much of this functionality and is therefore more complex.
Now, integrating these things in a central place has great potential to reduce the overall complexity and fragility and thereby make the system more secure. Take the various "sandboxing" features, including privilege dropping, restricting access to certain directories, private temp directories, settings separate namespaces, network isolation... For systemd, these are pretty easy to implement as part of setting up the services environment, which - as a service manager - must do anyway. In contrast, with SysV init, a separate program would have to be used; in practice this would be a set of shell scripts, or it would be integrated in the individual services, thus spreading the "risky" code over more places.
Additionally, systemd provides the system administrator with the means to setup these features easily (a few lines in a configuration file), relieving them from having to implement them themselves (which in some cases can even involve modifying and recompiling services!). Of course, in practice this means they aren't used at all. From a security point of view, the ini-style configuration format is also an advantage over the turing-complete shell scripts that are used with SysV init.
As for the development model behind systemd: I see this as an advantage compared to the alternative, because there is one central place where development (and extensive testing!) happens, which is in contrast to the previous mixture of mostly distribution specific code. Even the SysV init core itself differed between distributions, because its upstream can be considered dead. And contrary to what others say, systemd upstream is actually very responsive and open to reasonable change requests.
That said, I can see one situation where things are different, which is when the features provided by systemd aren't needed, for example if you want to build a router or a simple network gateway where the set of required services is known beforehand and will never change. Even there, you might want to take advantage of the easy-to-use sandboxing features, and this is anyway a special case that doesn't apply for the vast majority of systems.