[systemd-devel] Antw: [EXT] Re: Authenticated Boot: dm-integrity modes
>>> Wol schrieb am 28.11.2021 um 21:56 in Nachricht : > On 28/11/2021 19:56, Adrian Vovk wrote: >> - Journal mode: is slow. It atomically writes data+hash, so the >> situation I describe above can never happen. However, to pull this off >> it writes the data twice. Effectively every layer of journaled >> dm-integrity will cut write speeds in half. This isn't too bad to >> protect the rootfs since writes there will be rare, but it is terrible >> for /home. Layering systemd-homed's LUKS+dm-integrity image on top of >> that will cut performance in half again. So with the whole setup >> proposed by the blog post (even with dm-verity) writes to home will be >> limited to 1/4 of the drive's performance and the data will be written >> four times over. On top of performance issues, won't writing the data 4x >> wear out SSDs faster? Am I missing something? > > Why can't you just enable journalling in systemd-homed, so we have > LUKS+dm-integrity-journalling? > > If the user needs to separate / and /home, isn't that just sensible design? > > As for SSDs, the latest ones, as far as I can tell, have a lifespan > measured in years even if they're being absolutely hammered by a stress > test. If you're really worried about wearing out an SSD, put the journal > on rotating rust, but I think those in the know are likely to tell you > that the rust will die before the SSD. Today most storage technology is being replaced for larger capacity before it's old enough to fail. Some rusts survive many years. We had some making it for almost 10 years "24x7". SAo SSD we have is old enough. > > Cheers, > Wol
Re: [systemd-devel] Run reboot as normal user
Thanks, but I think using setuid has a security risk for attackers, so I understand there is no so much granularity to manage unprivileged access to systemd in case the polkit is not used. Best Regards, Mohamed Ali Le mar. 30 nov. 2021 à 13:00, Colin Guthrie a écrit : > Mohamed Ali Fodha wrote on 30/11/2021 10:35: > > Thank you for the answers, I am working on an embedded system and the > > polkit is not installed (not enabled at all in yocto build). > > I have a systemd service that run as a normal user and for some use case > > it requires to do a reboot > > I simulate it just for now as a dbus-send as shown below (just for debug > > - dbus-send will be replaced by a binary which will do the reboot) > > Previously the guest user was in sudoers (so to run reboot the systemd > > service uses "sudo") but actually our customer wants to remove the guest > > user from sudoers. > > Adding capabilities doesn't give me required permissions > > > > /[Service] > > User=guest > > ExecStart=dbus-send --system --print-reply > > --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 > > org.freedesktop.systemd1.Manager.StartUnit string:reboot.target > > string:replace-irreversibly > > AmbientCapabilities=CAP_SYS_BOOT CAP_SYS_ADMIN > > CapabilityBoundingSet=CAP_SYS_BOOT CAP_SYS_ADMIN > > / > > /[Install] > > WantedBy=multi-user.target/ > > If you will have a binary to do the commands then you should just do > that. It has to be a proper compiled binary (e.g. a simple C program). > > Make sure the binary is owned by root and group-owned by the same group > as your user (hopefully it has a private group) with group r+x > permission. "Other" should be nothing to prevent abuse. Make sure the > binary is marked as setuid. > > In the binary, ensure you call the appropriate commands to obtain root > privs (setruid()/setuid() etc. - can't remember off hand what to use) > > Then simply exec out to "systemctl reboot". > > That way although your user calls the binary, the binary then has > permission to become root and then "talk" to systemd to tell it to issue > the reboot. > > Capabilities shouldn't come into I don't think as all you're doing is > talking to systemd which does all the grunt work. > > HTHs > > Col > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: >Tribalogic Limited http://www.tribalogic.net/ > Open Source: >Mageia Contributor http://www.mageia.org/ >PulseAudio Hacker http://www.pulseaudio.org/ >Trac Hacker http://trac.edgewall.org/ > >
Re: [systemd-devel] Run reboot as normal user
Mohamed Ali Fodha wrote on 30/11/2021 10:35: Thank you for the answers, I am working on an embedded system and the polkit is not installed (not enabled at all in yocto build). I have a systemd service that run as a normal user and for some use case it requires to do a reboot I simulate it just for now as a dbus-send as shown below (just for debug - dbus-send will be replaced by a binary which will do the reboot) Previously the guest user was in sudoers (so to run reboot the systemd service uses "sudo") but actually our customer wants to remove the guest user from sudoers. Adding capabilities doesn't give me required permissions /[Service] User=guest ExecStart=dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:reboot.target string:replace-irreversibly AmbientCapabilities=CAP_SYS_BOOT CAP_SYS_ADMIN CapabilityBoundingSet=CAP_SYS_BOOT CAP_SYS_ADMIN / /[Install] WantedBy=multi-user.target/ If you will have a binary to do the commands then you should just do that. It has to be a proper compiled binary (e.g. a simple C program). Make sure the binary is owned by root and group-owned by the same group as your user (hopefully it has a private group) with group r+x permission. "Other" should be nothing to prevent abuse. Make sure the binary is marked as setuid. In the binary, ensure you call the appropriate commands to obtain root privs (setruid()/setuid() etc. - can't remember off hand what to use) Then simply exec out to "systemctl reboot". That way although your user calls the binary, the binary then has permission to become root and then "talk" to systemd to tell it to issue the reboot. Capabilities shouldn't come into I don't think as all you're doing is talking to systemd which does all the grunt work. HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [systemd-devel] Run reboot as normal user
Thank you for the answers, I am working on an embedded system and the polkit is not installed (not enabled at all in yocto build). I have a systemd service that run as a normal user and for some use case it requires to do a reboot I simulate it just for now as a dbus-send as shown below (just for debug - dbus-send will be replaced by a binary which will do the reboot) Previously the guest user was in sudoers (so to run reboot the systemd service uses "sudo") but actually our customer wants to remove the guest user from sudoers. Adding capabilities doesn't give me required permissions *[Service]User=guestExecStart=dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit string:reboot.target string:replace-irreversiblyAmbientCapabilities=CAP_SYS_BOOT CAP_SYS_ADMINCapabilityBoundingSet=CAP_SYS_BOOT CAP_SYS_ADMIN* *[Install]WantedBy=multi-user.target* Thank, Mohamed Ali Le mar. 30 nov. 2021 à 10:37, Colin Guthrie a écrit : > Mantas Mikulėnas wrote on 30/11/2021 08:42: > > On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha > > mailto:fodha.mohamed@gmail.com>> > wrote: > > > > Hello, > > > > I want to run reboot as normal user using the following command: > > dbus-send --system --print-reply --reply-timeout=2000 > > --type=method_call --dest=org.freedesktop.login1 > > /org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot > > boolean:false > > > > but I got a Permission denied error. > > > > I checked that verify_shutdown_creds (in logind-dbus.c) calls > > bus_verify_polkit_async, could it be the reason why I got permission > > denied error while polkit is not installed? > > > > > > Yes. Polkit is the authorization system that decides whether to allow > > normal users to do privileged actions or not. > > > > I don't want to use Polkit or sudo, is there any solution ? > > > > No. > > When you say you don't want to use polkit, are you just saying you want > to run dbus-send directly rather than prefixing it with pkexec or that > you really don't want polkit installed at all? > > If you don't mind having polkit installed and configured (doesn't have > to run all the time) then running dbus-send as above will just work as > you want (no need to run it via a pkexec wrapper). That's literally the > job of polkit - to allow certain privileged operations to users. > > If this isn't what you want you'll need to write your own suid wrapper > binary that calls the commands for you. > > Col > > >
Re: [systemd-devel] Run reboot as normal user
Mantas Mikulėnas wrote on 30/11/2021 08:42: On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha mailto:fodha.mohamed@gmail.com>> wrote: Hello, I want to run reboot as normal user using the following command: dbus-send --system --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot boolean:false but I got a Permission denied error. I checked that verify_shutdown_creds (in logind-dbus.c) calls bus_verify_polkit_async, could it be the reason why I got permission denied error while polkit is not installed? Yes. Polkit is the authorization system that decides whether to allow normal users to do privileged actions or not. I don't want to use Polkit or sudo, is there any solution ? No. When you say you don't want to use polkit, are you just saying you want to run dbus-send directly rather than prefixing it with pkexec or that you really don't want polkit installed at all? If you don't mind having polkit installed and configured (doesn't have to run all the time) then running dbus-send as above will just work as you want (no need to run it via a pkexec wrapper). That's literally the job of polkit - to allow certain privileged operations to users. If this isn't what you want you'll need to write your own suid wrapper binary that calls the commands for you. Col
Re: [systemd-devel] Run reboot as normal user
On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha < fodha.mohamed@gmail.com> wrote: > Hello, > > I want to run reboot as normal user using the following command: > dbus-send --system --print-reply --reply-timeout=2000 --type=method_call > --dest=org.freedesktop.login1 /org/freedesktop/login1 > org.freedesktop.login1.Manager.Reboot boolean:false > > but I got a Permission denied error. > > I checked that verify_shutdown_creds (in logind-dbus.c) calls > bus_verify_polkit_async, could it be the reason why I got permission denied > error while polkit is not installed? > Yes. Polkit is the authorization system that decides whether to allow normal users to do privileged actions or not. > I don't want to use Polkit or sudo, is there any solution ? > No. -- Mantas Mikulėnas
[systemd-devel] Run reboot as normal user
Hello, I want to run reboot as normal user using the following command: dbus-send --system --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot boolean:false but I got a Permission denied error. I checked that verify_shutdown_creds (in logind-dbus.c) calls bus_verify_polkit_async, could it be the reason why I got permission denied error while polkit is not installed? I don't want to use Polkit or sudo, is there any solution ? Best regards, Mohamed Ali
