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 1:29 PM, Dominick Grift dac.overr...@gmail.com wrote: 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 Do they have access to `cat /proc/self/mounts`? -- Mantas Mikulėnas graw...@gmail.com ___ 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 21.08.2015 12:04, Jóhann B. Guðmundsson wrote: Should not the solution for this be tied to the user and group field mentioned in the unit so for example the postgresql type service unit contains... User=postgres Group=postgres Which would mean that the posgres user could start,stop,restart,reload the postgresql.service as well as any user that has been added to the postgres group? For postgres it would probably solve this problem (as long as it's configurable), the question is whether you'd maybe rather want something a bit more generic for the future. I would suggest a setting like UnitControl=alice bob group:foobar that would enable alice, bob and everybody in group foobar to control that specific unit. (The name for the setting is debatable.) That would be quite simple but still very flexible and generic. The only problem I see is that for this to be useful, you'd need to be able to resolve the names, and you don't want to do that in pid 1. Question is whether PolicyKit (not pid 1) can do that check for systemd with systemd just passing along the whitelist somehow. (Don't know too much about PolicyKit yet to answer that question myself, unfortunately.) The same problem also applies to the solution of tying it to User=/Group=, however. Just my 2c. Christian signature.asc Description: OpenPGP digital 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, 21.08.15 13:29, Christian Seiler (christ...@iwakd.de) wrote: On 21.08.2015 12:04, Jóhann B. Guðmundsson wrote: Should not the solution for this be tied to the user and group field mentioned in the unit so for example the postgresql type service unit contains... User=postgres Group=postgres Which would mean that the posgres user could start,stop,restart,reload the postgresql.service as well as any user that has been added to the postgres group? For postgres it would probably solve this problem (as long as it's configurable), the question is whether you'd maybe rather want something a bit more generic for the future. I would suggest a setting like UnitControl=alice bob group:foobar that would enable alice, bob and everybody in group foobar to control that specific unit. (The name for the setting is debatable.) That would be quite simple but still very flexible and generic. The only problem I see is that for this to be useful, you'd need to be able to resolve the names, and you don't want to do that in pid 1. Question is whether PolicyKit (not pid 1) can do that check for systemd with systemd just passing along the whitelist somehow. (Don't know too much about PolicyKit yet to answer that question myself, unfortunately.) The same problem also applies to the solution of tying it to User=/Group=, however. systemd is not the place to implement ACL policy in. PolicyKit is that place. Hence: we should just pass the unit name to PK, and that's it. If you want to allow specific users access to an action on a unit, then encode that in PK rules. Lennart -- Lennart Poettering, Red Hat ___ 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 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 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) ___ 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
On Fri, Aug 21, 2015 at 1:43 PM, Dominick Grift dac.overr...@gmail.com wrote: 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 Right. That was my point. Restricting individual commands like `mount` is no good if you can't restrict the actual mechanism they all use… Mount namespaces might help here, as long as you don't use udisks/udisks2 (which, aside from leaking the same information, wouldn't even function correctly with per-user namespaces). [Though I don't really understand the point of hiding logged-in UIDs at all... Isn't hidepid=2 enough?] -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd doesn't delete netdev when parent interface is deleted
What workaround do you suggest in the meantime ? I'm currently using a very ugly hack which is an oneshot service that runs ip tunnel del right before the PPP service starts (and ignores eventual errors); is there a better way, possibly without touching the actual PPP service file (I'd like the tunnel to be self-contained in its netdev files). # /etc/systemd/system/ppp@orange.service [Unit] Description=PPP link to %I After=network.target tunnel-delete.service Wants=tunnel-delete.service [Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i updetach SuccessExitStatus=5 Restart=on-failure [Install] WantedBy=multi-user.target # /etc/systemd/system/tunnel-delete.service [Unit] Description=Delete remaining tunnel BindsTo=ppp@orange.service [Service] Type=oneshot ExecStartPre=-/bin/ip link set down dev heipv6 # horror starts here ExecStart=-/bin/ip tunnel del heipv6 # more nightmares On 2015-08-21 05:10, Susant Sahani wrote: yes right now we don't support deletion dynamically. Probably we would do that in future doing via networkctl. Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] About the state of two posts
Hello. I just re-read Lennart's posts (which i loved): - Factory Reset, Stateless Systems, Reproducible Systems Verifiable Systems and - Revisiting How We Put Together Linux Systems And i would like to know what's the state of both? Is there a place i can get news about this two subjects? Thanks FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/1] Rework systemd-rfkill
Currently systemd-rfkill does not support devices that lose power over suspend and do a disconnect()/probe() cycle (when the driver does not implement a reset_resume() callback): systemd-rfkill will restore the RFKill state that was saved on the last shutdown instead of the one right before suspending when udev detects the device was plugged. This happens for some Realtek Bluetooth adapters which lose their firmware during suspend. A fix for this problem is to add a udev rule to save the RFKill state on every change, so systemd-rfkill always have the most up-to-date state. This also removes the need for saving the RFKill state on shutdown, so systemd-rfkill@.service does not have to be active until shutdown, which in turn removes the need for the RFKill device units. This is also aligned with an item from systemd's TODO list (line 453). PS: Please let me know if this is not the preffered way of sending patches to systemd, as I've seen some activity on github. I can prepare a PR if needed. João Paulo Rechi Vita (1): rfkill: Rework systemd-rfkill Makefile-man.am | 12 -- Makefile.am | 6 --- TODO | 2 +- man/kernel-command-line.xml | 7 ++-- man/systemd-rfk...@.service.xml | 88 rules/99-systemd.rules.in| 5 ++- units/.gitignore | 1 - units/systemd-rfk...@.service.in | 23 --- 8 files changed, 7 insertions(+), 137 deletions(-) delete mode 100644 man/systemd-rfk...@.service.xml delete mode 100644 units/systemd-rfk...@.service.in -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] rfkill: Rework systemd-rfkill
This commit adds a udev rule to save the RFKill state on every change, so systemd-rfkill always have the most up-to-date state. This also removes the need for saving the RFKill state on shutdown, so systemd-rfkill@.service does not have to be active until shutdown, which in turn removes the need for the RFKill device units. Without this change systemd-rfkill does not support devices that lose power over suspend and do a disconnect()/probe() cycle (when the driver does not implement a reset_resume() callback): systemd-rfkill will restore the RFKill state that was saved on the last shutdown instead of the one right before suspending. This also removes an item from our TODO. --- Makefile-man.am | 12 -- Makefile.am | 6 --- TODO | 2 +- man/kernel-command-line.xml | 7 ++-- man/systemd-rfk...@.service.xml | 88 rules/99-systemd.rules.in| 5 ++- units/.gitignore | 1 - units/systemd-rfk...@.service.in | 23 --- 8 files changed, 7 insertions(+), 137 deletions(-) delete mode 100644 man/systemd-rfk...@.service.xml delete mode 100644 units/systemd-rfk...@.service.in diff --git a/Makefile-man.am b/Makefile-man.am index c0cebaa..0516d24 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1789,17 +1789,6 @@ man/systemd-resolved.html: man/systemd-resolved.service.html endif -if ENABLE_RFKILL -MANPAGES += \ - man/systemd-rfkill@.service.8 -MANPAGES_ALIAS += \ - man/systemd-rfkill.8 -man/systemd-rfkill.8: man/systemd-rfkill@.service.8 -man/systemd-rfkill.html: man/systemd-rfk...@.service.html - $(html-alias) - -endif - if ENABLE_SYSUSERS MANPAGES += \ man/sysusers.d.5 @@ -2336,7 +2325,6 @@ EXTRA_DIST += \ man/systemd-random-seed.service.xml \ man/systemd-remount-fs.service.xml \ man/systemd-resolved.service.xml \ - man/systemd-rfk...@.service.xml \ man/systemd-run.xml \ man/systemd-sleep.conf.xml \ man/systemd-socket-proxyd.xml \ diff --git a/Makefile.am b/Makefile.am index 2927757..a5e30ef 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4432,9 +4432,6 @@ if ENABLE_RFKILL rootlibexec_PROGRAMS += \ systemd-rfkill -nodist_systemunit_DATA += \ - units/systemd-rfkill@.service - systemd_rfkill_SOURCES = \ src/rfkill/rfkill.c @@ -4442,9 +4439,6 @@ systemd_rfkill_LDADD = \ libshared.la endif -EXTRA_DIST += \ - units/systemd-rfk...@.service.in - # -- if HAVE_LIBCRYPTSETUP rootlibexec_PROGRAMS += \ diff --git a/TODO b/TODO index ce50f16..17ec28c 100644 --- a/TODO +++ b/TODO @@ -450,7 +450,7 @@ Features: * unify dispatch table in systemctl_main() and friends -* rfkill,backlight: we probably should run the load tools inside of the udev rules so that the state is properly initialized by the time other software sees it +* backlight: we probably should run the load tools inside of the udev rules so that the state is properly initialized by the time other software sees it * After coming back from hibernation reset hibernation swap partition using the /dev/snapshot ioctl APIs diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml index eb73727..2a37275 100644 --- a/man/kernel-command-line.xml +++ b/man/kernel-command-line.xml @@ -114,10 +114,9 @@ listitem paraThis parameter is understood by several system tools to control whether or not they should restore system state - from the previous boot. For details, see - citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry - and - citerefentryrefentrytitlesystemd-rfkill@.service/refentrytitlemanvolnum8/manvolnum/citerefentry. + from the previous boot, like systemd-rfkill and + systemd-backlight. For more information, see + citerefentryrefentrytitlesystemd-backlight@.service/refentrytitlemanvolnum8/manvolnum/citerefentry. /para /listitem /varlistentry diff --git a/man/systemd-rfk...@.service.xml b/man/systemd-rfk...@.service.xml deleted file mode 100644 index 709b09d..000 --- a/man/systemd-rfk...@.service.xml +++ /dev/null @@ -1,88 +0,0 @@ -?xml version=1.0? -!--*-nxml-*-- -!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; -!-- - This file is part of systemd. - - Copyright 2013 Lennart Poettering - - systemd is free software; you can redistribute it and/or modify it - under the terms of the GNU Lesser General Public License as published by - the Free Software Foundation; either version 2.1 of the License, or - (at your option) any later version. - - systemd is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the
Re: [systemd-devel] Who has rights to override/ignore inhibitors?
Dear Lennart! That's what I have in my /usr/share/polkit-1/actions/org.freedesktop.login1.policy: action id=org.freedesktop.login1.power-off-ignore-inhibit descriptionPower off the system while an application asked to inhibit it/description messageAuthentication is required for powering off the system while an application asked to inhibit it./message defaults allow_anyauth_admin_keep/allow_any allow_inactiveauth_admin_keep/allow_inactive allow_activeauth_admin_keep/allow_active /defaults annotate key=org.freedesktop.policykit.implyorg.freedesktop.login1.power-off/annotate /action It seems like authentication IS required to poweroff system, disregarding inhibitors. However, on my system, without any special polkit configuration standard user (which is in the groups mentioned above) can ignore inhibitors by running systemctl poweroff -i without being asked for authentication. Could you please help me to understand, why is it so, and what should be done in order to change such behaviour? Yours, Jayson. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] rfkill: Rework systemd-rfkill
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1440172617-21794-2-git-send-email-jprvita%40endlessm.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV
Forwarding this again to the full list, On Mon, 2015-08-17 at 06:25 +, Keller, Jacob E wrote: Hi, -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Friday, August 14, 2015 10:52 PM To: Keller, Jacob E Subject: Re: [systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV Could you show lspci -t with VF created? \-[:00]-+-00.0 +-01.0-[01-03]00.0-[02-03]08.0-[03]--+-00.0 |+-00.3 |\-00.4 +-01.1-[04-05]--+-00.0 | +-00.1 | +-00.2 | \-00.3 +-02.0-[06-09]00.0-[07-09]--+-08.0-[08]--+-00.0 | |+-00.1 | |+-00.2 | |+-00.3 Just to be sure - which are your devices? You indicated it is PCI bus 5 (enp5s1f0) but there are no devices for it shown. Could you send me both lspci -tv and lspci indicating which of these are your VF devices? Thank you! Sorry the examples I used above were not the actual device name. My PF device is :08 :00.0 It shows up as slot 8 in /sys/bus/pci/slots/8/address/ My VF device(s) are :08:00.1 through :08:08.0 There are 64 of them. The hardware doesn't lay them out on the same slot since there are only 8 functions per slot. Regards, Jake Is that enough information? Basically, hotplug slot style names are breaking when I use SR-IOV because the VFs don't get detected as inthe same hotplug slot (because the bus:slot.func changes..) Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Partition with random key in crypttab
Hi, I'm not experienced at all with systemd, and not much more in system administration, and I don't know if I should post this here, but it is the only list I found that seems to provide general support for systemd. I want to encrypt my /tmp directory by putting it in an encrypted partition (sda9). I put the following line in /etc/crypttab : crypttmp /dev/sda9 /dev/urandom tmp=ext4,cipher=aes,size=256,hash=sha256 ...and the following in /etc/fstab : /dev/mapper/crypttmp /tmp ext4 defaults 0 2 but when I boot, systemd hangs for 1:30, saying that a startup job is running for dev-mapper-crypttmp. Then it fails, and the encrypted tmp is not mounted. I'm on Debian Jessie, if it can help. What is the recommended way to mount an encrypted partition with a random key ? Thanks. ___ 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
On Fri, Aug 21, 2015 at 12:57 PM, Dominick Grift dac.overr...@gmail.com wrote: 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. Hmm, and `findmnt` doesn't? `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. -- Mantas Mikulėnas graw...@gmail.com ___ 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
