Innitab deprecation

Can anyone who really understands abstraction and protection rings explain why innitab is no longer used when using systemd?
As opposed to hierarchical protection domains, what is an example of capability based security?
Responses
An example of capability based security is kernel capabilities, ie. a list of capabilities a process has access (is restricted) to:
http://man7.org/linux/man-pages/man7/capabilities.7.html
Don't really follow the question without more context. inittab is gone in RHEL 7, this isn't a RHEL 7.5 specific change.
The rings are a way to break security out into different levels of privilege. Processes are only given access to the 'ring' with the least amount of privilege (outermost) required to carry out the required task. Movement between the rings is enforced/restricted.
Probably easier to just read the Wikipedia page that it looks like the whiteboard quote came from:
https://en.wikipedia.org/wiki/Protection_ring
To elaborate on:
_ inittab is gone in RHEL 7, this isn't a RHEL 7.5 specific change._
/etc/inittab isn't so much "gone" in RHEL 7 as much as it's vestigial. You'll still find that it exists, and per the file's contents:
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To view current default target, run:
# systemctl get-default
#
# To set a default target, run:
# systemctl set-default TARGET.target
#
It's non-functional. The inittab doesn't have a useful context within the systemd framework. Its functionalities are subsumed by systemd and you need to do your inittab-ish stuff via systemd units, instead.
The capabilities subsystem has been in RHEL for quite a while, now. However, like SELinux, a lot of people — particularly those that don't use container-technologies — haven't used it. The capabilities system isn't sub-component of systemd, but systemd can use it to enhance its own functioning (e.g., providing more isolation between launched units).
Sure, if we're arguing semantics it's not 'gone'.
By 'gone' I am saying the files functionality is removed. The file that remains is to essentially provide an instructional, documented process to achieve the same functions through systemd which should makes this clear to anyone looking.
Agreed, most modern interactions with kernel capabilities will be through use of containers. Good summary of capabilities + containers and what they provide here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/linux_capabilities_and_seccomp
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
