Re: [systemd-devel] /etc/machine-id has wrong SELinux file context and changes on second boot
It is a policy configuration issue obviously. I am not sure what version of reference policy Yocto is using in that environment but you might want to see if it is old. SELinux policy is very dynamic. Frankly, according to my security policy systemd-machine-id-setup is selinux aware like many systemd components and so it should address labeling programmatically (if it is allowed to by the policy selinux enforces) Can you produce this issue with selinux in permissive mode? If it works in permissive mode but not in enforcing mode then selinux is blocking systemd-machine-id-setup and that might cause the labeling issue. By the way I would argue that both init_runtime_t and etc_runtime_t are not suitable for this and that it should probably have a private machineid_t type since AFAIK this /etc/machine-id is only ever created by systemd-machine-id-setup. "Sebert, Holger.ext" writes: > Hi! > > I am having issues with systemd's machine-id: On first boot it is > created, i.e. the file /etc/machine-id changes from “unintialized” to a > hash value; but it has the wrong SELinux file context, namely > “init_runtime_t”. > > Furthermore, I am getting the following error message: > > localhost systemd[1]: systemd-machine-id-commit.service: Main process exited, > code=exited, status=1/FAILURE > localhost systemd-machine-id-setup[424]: Failed to unmount transient > /etc/machine-id file: No such file or directory. > localhost systemd-machine-id-setup[424]: We keep that mount until next reboot. > localhost systemd[1]: systemd-machine-id-commit.service: Failed with result > 'exit-code'. > > On the next boot, /etc/machine-id has the correct SELinux file context, > namely, “etc_runtime_t”, but the ID has changed! On subsequent boots, > it remains unchanged, however. > > I think this could be related to this old bug: > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140 > > And, indeed, we are also using OverlayFS (in a Yocto/Poky (mickledore) > environment). > > Do you have an idea how to work around this problem? > > Best, > Holger -- gpg --locate-keys dominick.gr...@defensec.nl (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcini...@defensec.nl
[systemd-devel] systemd-pcrlock Failed to submit super PCR policy
7+18+19+20+21+22+23)] Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0005 property 0x count 1. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0008 property 0x count 508. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0002 property 0x011f count 256. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x property 0x0001 count 127. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: TPM successfully started up. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Loaded TCTI module 'tcti-device' (TCTI module for communication with Linux kernel interface.) [Version 2] Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Using TPM2 TCTI driver 'device' with device '/dev/tpmrm0'. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x04 subtype=0x03 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x04 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x03 subtype=0x17 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x02 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x04 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x03 subtype=0x17 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x02 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x04 subtype=0x08 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x02 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x04 subtype=0x08 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x01 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Ignoring device path element type=0x02 subtype=0x01 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: TPM PC Client Platform Firmware Profile: family 2.0, revision 0.0 Feb 04 20:00:01 nimbus systemd[1]: Starting systemd-pcrlock-make-policy.service - Make TPM2 PCR Policy... Dump a new UKI into /boot/EFI/Linux and reboot Question is: How do I interpret and deal with this situation? Thanks -- gpg --locate-keys dominick.gr...@defensec.nl (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcini...@defensec.nl
Re: [systemd-devel] [systemd SELinux] system status permission
On Mon, Oct 07, 2019 at 06:51:57PM +0200, Dominick Grift wrote:
> On Mon, Oct 07, 2019 at 11:03:44AM -0500, Ian Pilcher wrote:
> > I am hitting this (non-fatal) denial when reloading a service via the
> > systemd dbus API:
> >
> > > type=USER_AVC msg=audit(1570462081.809:743): pid=1 uid=0
> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > msg='avc: denied { status } for auid=n/a uid=0 gid=1001
> > > cmdline="/usr/bin/python2 /usr/local/bin/test.py"
> > > scontext=system_u:system_r:denatc_t:s0
> > > tcontext=system_u:system_r:init_t:s0 tclass=system
> > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > https://selinuxproject.org/page/NB_ObjectClassesPermissions defines this
> > permission as "Get system status information," which isn't particularly
> > helpful.
> >
> > Ultimately, I need to decide whether to allow or "dontaudit" this
> > denial, so any information/pointers on what systemd is doing here and
> > what functionality I will lose if I dontaudit this denial would be
> > appreciated.
>
> Not sure but this is my best bet:
>
> Generally, i think, its about "getting" information from systemd1, as opposed
> to setting things.
>
> Stuff like: introspection, getting info about objects it manages, about it's
> properties.
>
> Theres a lot of "status information" to be gotten I guess. Introspect
> systemd1 to see what all is there.
>
> But if you reload a unit, I gather, you might get some status information
> about it from systemd1.
>
> I guess you can probably see the methods that are being invoked if you set
> the systemd loglevel to debug
>
> systemd-analyze log-level debug && systemctl reload foo && journalctl -rb
I tried it out with simple `systemctl status`
Oct 07 19:04:21 myguest systemd[1]: Sent message type=method_return
sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a
member=n/a cookie=1 reply_cookie=1 signature=a{sv} error-name=n/a
error-message=n/a
Oct 07 19:04:21 myguest systemd[1]: SELinux access check
scon=wheel.id:sysadm.role:systemctl.sysadm.subj:s0
tcon=sys.id:sys.role:systemd.system.subj:s0 tclass=system perm=status
path=(null) cmdline=: 0
Oct 07 19:04:21 myguest systemd[1]: Got message type=method_call sender=n/a
destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0
signature=s error-name=n/a error-message=n/a
So the method "get all properties from systemd1" was called by running that,
and that triggered a "system status" check
>
> >
> > Thanks!
> >
> > --
> >
> > Ian Pilcher arequip...@gmail.com
> > "I grew up before Mark Zuckerberg invented friendship"
> > ====
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd SELinux] system status permission
On Mon, Oct 07, 2019 at 11:03:44AM -0500, Ian Pilcher wrote:
> I am hitting this (non-fatal) denial when reloading a service via the
> systemd dbus API:
>
> > type=USER_AVC msg=audit(1570462081.809:743): pid=1 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > msg='avc: denied { status } for auid=n/a uid=0 gid=1001
> > cmdline="/usr/bin/python2 /usr/local/bin/test.py"
> > scontext=system_u:system_r:denatc_t:s0
> > tcontext=system_u:system_r:init_t:s0 tclass=system
> > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> https://selinuxproject.org/page/NB_ObjectClassesPermissions defines this
> permission as "Get system status information," which isn't particularly
> helpful.
>
> Ultimately, I need to decide whether to allow or "dontaudit" this
> denial, so any information/pointers on what systemd is doing here and
> what functionality I will lose if I dontaudit this denial would be
> appreciated.
Not sure but this is my best bet:
Generally, i think, its about "getting" information from systemd1, as opposed
to setting things.
Stuff like: introspection, getting info about objects it manages, about it's
properties.
Theres a lot of "status information" to be gotten I guess. Introspect systemd1
to see what all is there.
But if you reload a unit, I gather, you might get some status information about
it from systemd1.
I guess you can probably see the methods that are being invoked if you set the
systemd loglevel to debug
systemd-analyze log-level debug && systemctl reload foo && journalctl -rb
>
> Thanks!
>
> --
>
> Ian Pilcher arequip...@gmail.com
> "I grew up before Mark Zuckerberg invented friendship"
> ====
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
On Fri, Aug 21, 2015 at 08:25:56PM +1000, Daurnimator wrote: On 21 August 2015 at 19:57, Dominick Grift dac.overr...@gmail.com wrote: i think it kind of sucks that systemctl --user list-units can be used to determine who is currently logged in. You can see with `loginctl list-users` too My restricted users currently cannot run loginctl. If they could then there may or may not be a way to transperantly deny access to that info using selinux (not sure i would have to try it) I once tried to prevent getting a list of users, but it's hard... I locked out: - `w` and `who` (uses /var/run/utmp; do chmod o-r) - `grep -h '^Uid:' /proc/*/status | sort -u` (prevent with procfs option hidepid=2) - ls /run/user (do chmod o-r) I think i do have it working currently (at least mostly). Except for systemctl --user list-units I am basically using SELinux to isolate processes based on roles and types access to wtmp is denied with TE access to process state is isolated using RBACSEP access to df -h is restricted to generic file systems only (tmpfs fs doesnt show up access to pts/ttys and other files are isolated using RBACSEP -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgprho2Dj9DuW.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
On Fri, Aug 21, 2015 at 01:10:51PM +0300, Mantas Mikulėnas wrote: snip i think it kind of sucks that systemctl --user list-units can be used to determine who is currently logged in. ( it shows active mount units for XDG_RUNTIME_DIR and since those have UID as name you can see who is logged in. Hmm, and `findmnt` doesn't? unpriv users do not have access to mount or findmount in my system, and for example df -h does not list them because the user is not allowed to get attributes of tmpfs file systems. So /run/user mounts do not show up in df -h `systemd --user` runs with the same privileges as the user, anyway. So if your SELinux policy is more permissive to systemd than regular programs, it's a bit weird, not to mention possibly insecure. From an SEinux policy perspective systemd-user has more permissions than the user shell in my policy. However systemd-user will run whatever it can run with the permissions of the user shell and not with its own permissions. So you cannot use systemd-user to escalate privileges (although that is the design. I may have overlooked stuff as it is pretty complex to contain.) I am pretty sure that some bright person can find some holes in my policy but its far better than no selinux at all and its better than Fedoras' current selinux policy for restricted users -- Mantas Mikulėnas graw...@gmail.com -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpNZmfN8MOtq.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
On Fri, Aug 21, 2015 at 01:38:28PM +0300, Mantas Mikulėnas wrote: Do they have access to `cat /proc/self/mounts`? Ouch yes... ok that is a dead end i suppose -- Mantas Mikulėnas graw...@gmail.com -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgplvuCg2ZlLW.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
Made a demo because i was bored: https://www.youtube.com/watch?v=KrK5a7D77l0 In practice though this is probably not an option for you. It is very expensive. however it is (optionally) supported by systemd and i just wanted to counter the misinformation. i think it kind of sucks that systemctl --user list-units can be used to determine who is currently logged in. ( it shows active mount units for XDG_RUNTIME_DIR and since those have UID as name you can see who is logged in. also unpriv users can get status of system services by default? -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
systemd has a built-in extension to the SELinux MAC framework. If that,
and SELinux is enabled. Then you can use the SELinux framework and
systemd SELinux extension to configure which services may be controlled
by specified processes on a fined grained level using mandatory access control.
Policykit to allow unpriv users to manage system services, additional
layer of SELinux MAC config to narrow that down to only specified
services by labeling the units and systemctl to specifying
which labeled unit, a labeled systemctl can control.
allow joe_systemctl_t postgresql_unit_t:service { start stop status };
--
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788
Dominick Grift
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] systemd-222 around the corner
Would be nice if anyone could at least confirm or deny this issue that I've identified in systemd-nspawn since v220: https://bugzilla.redhat.com/show_bug.cgi?id=1232371 Containers that rely on that functionality stopped working for me since v220 -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpFIFO8nUgqE.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] systemd-222 around the corner
On Tue, Jul 07, 2015 at 09:56:45AM +0100, Richard Maw wrote: On Tue, Jul 07, 2015 at 09:25:21AM +0300, Andrei Borzenkov wrote: On Tue, Jul 7, 2015 at 9:02 AM, Dominick Grift dac.overr...@gmail.com wrote: Would be nice if anyone could at least confirm or deny this issue that I've identified in systemd-nspawn since v220: https://bugzilla.redhat.com/show_bug.cgi?id=1232371 Containers that rely on that functionality stopped working for me since v220 Ddi you open github issue for that? I did. https://github.com/systemd/systemd/issues/475 I've got a local fix with https://github.com/systemd/systemd/pull/483, but it's pending discussion with Dan Walsh about whether this should be the fix, and https://github.com/systemd/systemd/pull/500 would make the work-around cleaner. I do not see why this needs walsh' input. This setexeccon() functionality is implemented all over the place (svirt, selinux-sandbox etc). If it would be compelling to deal with that in either libselinux or glibc then it probably would have been dealth with there already. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpJY91AYbLtv.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] selinux: fix missing SELinux unit access check
Development has moved to github.com/systemd It is probably better to submit a Github Push Request there if you have not done so already. Thanks -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpLns3mVGvdM.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering lennart at poettering.net: Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. But it is okay for networkd to manipulate the firewall directly. Yes, networkd configures the network. That's its raison d'etre. Thanks for clearing that up. I alway's thought firewalls were a security thing, and that netfilter is mandatory access control framewark that should be, mostly, transparent to applications and services. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpbPvtZbgCoo.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering lennart at poettering.net: Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. But it is okay for networkd to manipulate the firewall directly. The nft manual page states that the iptable_nat module conflicts with the module that deals with nftables nat. Does that mean that the networkd IPMasquerade= functionality will not work if one blacklists iptables_nat? -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpNEepiniQub.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
For the sock *file*, i would argue, that indeed the setfscreatecon is not strictly needed, and that the labeling for this can be taken care of by using type transition rules in the security policy as suggested. However for the socket classes associated with the process type, setsockcreatecon is required The socket activation selinux related aspect has two parts: 1. the socket associated with the process (setsockcreatecon()) 2. the actual socket file (setfscreatecon()) The latter (2) can, and should *probably* be removed. The setsockcreatecon() stuff should stay, and the setfscreatecon() stuff should *probably* go. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpuyk4nWBLag.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
On Wed, Mar 25, 2015 at 10:31:41PM +0100, Dominick Grift wrote: For the sock *file*, i would argue, that indeed the setfscreatecon is not strictly needed, and that the labeling for this can be taken care of by using type transition rules in the security policy as suggested. However for the socket classes associated with the process type, setsockcreatecon is required The socket activation selinux related aspect has two parts: 1. the socket associated with the process (setsockcreatecon()) 2. the actual socket file (setfscreatecon()) The latter (2) can, and should *probably* be removed. The setsockcreatecon() stuff should stay, and the setfscreatecon() stuff should *probably* go. Actually, come to think about it, it is not that simple and things should probably stay as they are. For multi level security configurations the proper security level must be associated with the sock file, and that cannot be specified with a type transition rule. It should stay the way it currently is. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpzL_PeTYa_Q.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
