Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Run reboot as normal user

[Mohamed Ali Fodha]

According to this thread https://github.com/systemd/systemd/issues/11034,
kdbus can manage linux capabilities but dbus can't, isn't it?
Below is what I did in my binary















* r = sd_bus_open_system(&bus); if (r < 0) { sm_error("Failed to
connect to system bus\n"); } r = sd_bus_call_method(bus,
 "org.freedesktop.systemd1",  "/org/freedesktop/systemd1",
   "org.freedesktop.systemd1.Manager",   "StartUnit",
  &error, &m,
 "ss",
   "reboot.target",
 "replace-irreversibly");*

This call returns -13 (#define EACCES 13 /* Permission denied */)
Below are the capabilities of the binary (hwmanager is called by regular
user)

*root@imx6quad:~# getcap /usr/sbin/hwmanager*

*/usr/sbin/hwmanager  =
cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_kill,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_rawio,cap_sys_admin,cap_sys_boot,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_syslog+eip*

Mohamed Ali

Le mer. 1 déc. 2021 à 11:38, Ulrich Windl 
a écrit :

> >>> Martin Wilck  schrieb am 01.12.2021 um 10:41 in
> Nachricht
> :
> > On Wed, 2021‑12‑01 at 10:24 +0100, Ulrich Windl wrote:
> >> > >
> >>
> >> And I wonder what's wrong with allowing the shutdown command for the
> >> user in
> >> sudoers.
> >> (sudo $(which shutdown) ‑r now)
> >
> > Sure. I thought sudo might not be installed on that embedded system,
> > either. If it is, I'd prefer it over other solutions simply because
> > it's more transparent. Capability bits tend to go unnoticed.
> >
>
> Quote from OP: "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."
>
> It was some odd security debate: If someone can operate as guest he/she
> should
> not be able to reboot, while the guest user should be.
> (Maybe I misunderstood. Any case some details for the problem are missing)
>
>
> > Martin
>
>
>
>

Re: [systemd-devel] Authenticated Boot: dm-integrity modes

[Adrian Vovk]

Some more thoughts about the usefulness of dm-integrity:

1. There's some past work[1] on authenticated Btrfs, where the whole 
filesystem is authenticated w/ a keyed hash algorithm. It's basically 
dm-integrity built directly into the filesystem, with none of the 
performance and complexity penalty. I think it makes a lot more sense 
to reuse Btrfs's already-existing hashing infrastructure with HMAC than 
to put a second layer of integrity checking under it. Perhaps pushing 
for that work to land in the kernel is a better use of time than 
working around dm-integrity's limitations? I'd like to hear your 
thoughts on this most.


2. Integrity-checking all the filesystems that will be mounted is 
infeasible. Here's two cases I can think of right off the bat:
- At some point, to do a system update, the ESP or the XBOOTLDR 
partition will be mounted by userspace. What if these filesystems are 
maliciously constructed to exploit the kernel? It's not possible to use 
any kind of integrity checking on these filesystems because they're 
read by things outside of the kernel (firmware, bootloader). Maybe the 
filesystem can be constructed to exploit the (notoriously poorly 
implemented) UEFI firmware itself!
- Any USB stick the user will plug into the computer *might* have a 
malicious filesystem on it. The only way to protect against this is to 
never mount USB sticks plugged into the device. Asking for an 
admin/root password will just be an annoyance and users will type it 
in. There's really no way around it; users will have to occasionally 
mount untrusted filesystems on their machine


3. What is dm-integrity protecting in the homed image? Assuming /home 
is protected from offline writes, there's no way an attacker can modify 
the contents of the loopback file anyways. Why layer dm-integrity on 
top of that?


[1]: 



Regards,
Adrian

Re: [systemd-devel] Authenticated Boot: dm-integrity modes

[Adrian Vovk]

> Why can't you just enable journalling in systemd-homed, so we have
LUKS+dm-integrity-journalling?

That's why there's two layers of dm-integrity stacked on top of each 
other (one protecting the filesystem, one baked into the systemd-homed 
LUKS image)


> If the user needs to separate / and /home, isn't that just sensible 
design?


I'm not exactly sure what you mean by this, sorry

> 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.

This is for a general-purpose desktop OS. I have absolutely no control 
over the hardware my users have in their computers. Many SSDs from a 
few years ago have significantly worse lifetimes. I'd rather not wear 
out the SSD 4x more than necessary (even if many newer SSDs can handle 
that)


Best,
Adrian

Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

[Brian Hutchinson]

Hey Andrei,

On Wed, Dec 1, 2021 at 1:51 PM Andrei Borzenkov  wrote:

> On 01.12.2021 17:20, Brian Hutchinson wrote:
> > Hi,
> >
> > I'm on embedded imx8 mm platform and trying to order services such that
> > ptp4l (LinuxPTP) is started after a bond is created between two DSA
> network
> > interfaces on my Microchip Ethernet Switch.
> >
> > No matter what I try with BindsTo, Wants=, Requires=, Before=, After=,
> when
> > the board boots and I watch the console output I see systemd start the
> > ptp4l service before the bond is actually up which results in ptp4l
> failing
> > to start.
> >
> ...>
> > Is it also possible to use carrier state in .service file?
> >
>
> I do not think it is possible. I have seen similar request (possibility to
> initiate action when interface is up) more than once, but so far nothing
> happened.
>

... I was afraid you were going to say something like that ;).

Bummed out,

Brian

Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

[Brian Hutchinson]

Hey James,

Thanks!  Responses below

On Wed, Dec 1, 2021 at 1:12 PM James Feeney  wrote:

> On 12/1/21 07:20, Brian Hutchinson wrote:
> > ...
> > In .system file I tried all I know to ensure the required interfaces
> were created before starting ptp4l in attempt to give bonding enough time
> to finish but binding to things like sys-subsystem-net-devices-bond1.device
> wasn't enough.
> >
> > Is it also possible to use carrier state in .service file?
> >
> > I see sys/devices/virtual/net/bond1/carrier but not sure how to only
> attempt to start my ptp4l service after carrier state is "1".
> >
> > I welcome your ideas and suggestions on how to start a service after a
> bond interface is really up.
>
> With systemd, the proper way to setup network bonding is to establish
> ordering with the use of "target" files, which can be added to
> /etc/systemd/system.
>
> The target files themselves need not contain anything, though I have these
> with simply:
>
> [Unit]
> Documentation= man:systemd.target(5)
>
> My configuration provides automatic bonding and bridging for
> removable/pluggable and fixed hardwired, wireless, and virtual interfaces,
> using hardlinked template files and a separate network configuration file,
> as /etc/conf.d/network, though you are only looking for bonding here.  The
> big advantage with using systemd as the network configuration system,
> compared to alternatives, is that it "just works", and doesn't break after
> someone else's "upgrade".
>

Your hardware situation is certainly more interesting than mine with
hotplug stuff ... in the old days I had to do udev rules for stuff like
that but with this project I decided to finally go with systemd.  For the
most part it does "just work" until it "doesn't" and I've ran into that
quite a few times now and this is one of those cases (note I'm on
linux-fslc-imx 5.10.69 and I understand some bonding issues have been fixed
in 5.11 but I don't think that fix pertains to what I'm seeing here).
There are hooks to guarantee the "network is online" before going on ...
and they don't work right in this case.  You can see from my serial console
log bond1 isn't up until after the login prompt and all the systemd targets
have finished! And systemd was told not to start ptp4l until after the
network is up and you can clearly see it being started before bond1 is up.


> The essential idea with configuring virtual network interfaces using
> systemd target files derives from noting that network service clients and
> servers must run After bridge and bond master interfaces are working, which
> implies After configuration of their respective slave interfaces, and that
> hardware devices can only be enslaved After the master interfaces have been
> created.  These constraints imply the following ordering:
>
> 1) master interfaces
> 2) enslaved interfaces
> 3) network services
>
> The systemd target files are then inferred between these three stages:
>
> a) master interfaces
> b) "go.target"
> c) enslaved interfaces
> d) "ll.target"
> e) network services
>
> The target file naming is arbitrary, of course.  I use these names from
> arbitrarily choosing the point of view from the template file used to
> configure each slave device to each master, where finally "ip link set %P
> master %I".
>
> You could use the terminology "director" and "executive", from corporate
> structure lingo, instead of "master" and "slave", if preferred, but the ip
> command still uses the the terms "master" and "slave".
>
> A hardware network device Requires go.target and the master interface
> service file "master@.service" runs Before go.target:
>
> Requires= go.target
> Before= go.target
>
> Plugging network hardware, then, will trigger the entire chain of
> configuration events.
>
> BindsTo= sys-subsystem-net-devices-%i.device
>
> Similarly, for the enslaved interface service file "enslaved@.service":
>
> Requires= go.target
> After= go.target
> Before= ll.target
>
> And finally, for the various network services service template files:
>
> PartOf= ll.target
> Requires= ll.target
> After= ll.target
>
> That's the basic idea.  Of course, there are plenty of "housekeeping"
> details in practice.  In particular, "Requisite" fails to recognize device
> units, and instead,
>
> ConditionPathExists= /sys/class/net/%I
>
> is necessary.  This appears to me to be an unjustified bug with
> "Requisite", but - you know - Lennart.
>
> Altogether, to trigger configuration of both master and slave devices from
> "enslaved@.service":
>
> BindsTo= sys-subsystem-net-devices-%p.device
> ConditionPathExists= /sys/class/net/%P
> BindsTo= sys-subsystem-net-devices-%i.device
>
> It is useful to impose an arbitrary but strict naming convention with
> these files, to allow use of systemd specifiers and template files.  In
> your case, you might simply hard-code what you want, if you are not looking
> for a generic solution, and all you want is bonding on a couple of
> interfaces.
>
> Still, when properly setup, 

Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

[Andrei Borzenkov]

On 01.12.2021 17:20, Brian Hutchinson wrote:
> Hi,
> 
> I'm on embedded imx8 mm platform and trying to order services such that
> ptp4l (LinuxPTP) is started after a bond is created between two DSA network
> interfaces on my Microchip Ethernet Switch.
> 
> No matter what I try with BindsTo, Wants=, Requires=, Before=, After=, when
> the board boots and I watch the console output I see systemd start the
> ptp4l service before the bond is actually up which results in ptp4l failing
> to start.
> 
...> 
> Is it also possible to use carrier state in .service file?
> 

I do not think it is possible. I have seen similar request (possibility to
initiate action when interface is up) more than once, but so far nothing
happened. 

This would be similar to NetworkManager dispatcher script.

It does not really fit into service dependency at all.

Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

[James Feeney]

On 12/1/21 07:20, Brian Hutchinson wrote:

...
In .system file I tried all I know to ensure the required interfaces were 
created before starting ptp4l in attempt to give bonding enough time to finish 
but binding to things like sys-subsystem-net-devices-bond1.device wasn't enough.

Is it also possible to use carrier state in .service file?

I see sys/devices/virtual/net/bond1/carrier but not sure how to only attempt to start my 
ptp4l service after carrier state is "1".

I welcome your ideas and suggestions on how to start a service after a bond 
interface is really up.


With systemd, the proper way to setup network bonding is to establish ordering with the 
use of "target" files, which can be added to /etc/systemd/system.

The target files themselves need not contain anything, though I have these with 
simply:

[Unit]
Documentation= man:systemd.target(5)

My configuration provides automatic bonding and bridging for removable/pluggable and fixed 
hardwired, wireless, and virtual interfaces, using hardlinked template files and a separate network 
configuration file, as /etc/conf.d/network, though you are only looking for bonding here.  The big 
advantage with using systemd as the network configuration system, compared to alternatives, is that 
it "just works", and doesn't break after someone else's "upgrade".

The essential idea with configuring virtual network interfaces using systemd 
target files derives from noting that network service clients and servers must 
run After bridge and bond master interfaces are working, which implies After 
configuration of their respective slave interfaces, and that hardware devices 
can only be enslaved After the master interfaces have been created.  These 
constraints imply the following ordering:

1) master interfaces
2) enslaved interfaces
3) network services

The systemd target files are then inferred between these three stages:

a) master interfaces
b) "go.target"
c) enslaved interfaces
d) "ll.target"
e) network services

The target file naming is arbitrary, of course.  I use these names from arbitrarily 
choosing the point of view from the template file used to configure each slave device to 
each master, where finally "ip link set %P master %I".

You could use the terminology "director" and "executive", from corporate structure lingo, instead of "master" 
and "slave", if preferred, but the ip command still uses the the terms "master" and "slave".

A hardware network device Requires go.target and the master interface service file 
"master@.service" runs Before go.target:

Requires= go.target
Before= go.target

Plugging network hardware, then, will trigger the entire chain of configuration 
events.

BindsTo= sys-subsystem-net-devices-%i.device

Similarly, for the enslaved interface service file "enslaved@.service":

Requires= go.target
After= go.target
Before= ll.target

And finally, for the various network services service template files:

PartOf= ll.target
Requires= ll.target
After= ll.target

That's the basic idea.  Of course, there are plenty of "housekeeping" details in 
practice.  In particular, "Requisite" fails to recognize device units, and instead,

ConditionPathExists= /sys/class/net/%I

is necessary.  This appears to me to be an unjustified bug with "Requisite", 
but - you know - Lennart.

Altogether, to trigger configuration of both master and slave devices from 
"enslaved@.service":

BindsTo= sys-subsystem-net-devices-%p.device
ConditionPathExists= /sys/class/net/%P
BindsTo= sys-subsystem-net-devices-%i.device

It is useful to impose an arbitrary but strict naming convention with these 
files, to allow use of systemd specifiers and template files.  In your case, 
you might simply hard-code what you want, if you are not looking for a generic 
solution, and all you want is bonding on a couple of interfaces.

Still, when properly setup, you can individually "start" and "stop" any of the 
target units or network service units and get correct behavior.


James

[systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

[Brian Hutchinson]

Hi,

I'm on embedded imx8 mm platform and trying to order services such that
ptp4l (LinuxPTP) is started after a bond is created between two DSA network
interfaces on my Microchip Ethernet Switch.

No matter what I try with BindsTo, Wants=, Requires=, Before=, After=, when
the board boots and I watch the console output I see systemd start the
ptp4l service before the bond is actually up which results in ptp4l failing
to start.

I've band-aided the issue by putting a Restart=yes and RestartSec=1 in the
service but feel like this is a hack.

As you can see below, the bond is in the process of coming up (you can see
enslaving messages regarding lan1 and lan2) but it is not all the way up
until after the login prompt ... at which point the service starting ptp4l
(the Sync Microchip PHC with PTP Grand Master  Clock msg) already failed.
>From timestamps it looks like it's taking 4 seconds or so for bond to come
up:

[  OK  ] Started Network Service.
Starting Network Name Resolution...
[  OK  ] Started Rauc Good-marking Service.
[4.098258] imx-sdma 302c.dma-controller: firmware found.
[4.104259] imx-sdma 302c.dma-controller: loaded firmware 4.5
[  OK  ] Started Network Name Resolution[4.135108] imx-sdma
302b.dma-controller: firmware found.
.
[  OK  ] Reached targe[4.146220] imx-sdma 30bd.dma-controller:
firmware found.
t Network.
[  OK  ] Reached targe[4.159060] caam-snvs 3037.caam-snvs:
violation handlers armed - init state
t Network is Online.
[  OK  ] Reached target Host and Network Name Lookups.
Starting Avahi mDNS/DNS-SD Stack...
Starting Enable ksz9567...
Starting The NGINX HTTP and reverse proxy server...
[  OK  ] Started Enable ksz9567.
[  OK  ] Started Avahi mDNS/DNS-SD Stack.
[  OK  ] Found device /sys/subsystem/net/devices/lan2.
[  OK  ] Started The NGINX HTTP and reverse proxy server.
[4.390005] ksz9477-switch 0-005f lan2: configuring for phy/gmii link
mode
[4.402902] bond1: (slave lan2): Enslaving as a backup interface with a
down link
[  OK  ] Found device [4.544105] ksz9477-switch 0-005f lan1:
configuring for phy/gmii link mode
/sys/subsystem/net/devices/lan1.
[4.555298] bond1: (slave lan1): Enslaving as a backup interface with a
down link
[  OK  ] Found device /sys/subsystem/net/devices/bond1.
Starting Save/Restore Sound Card State...
[  OK  ] Started Save/Restore Sound Card State.
[  OK  ] Reached target Sound Card.
[6.714002] random: crng init done
[6.717436] random: 7 urandom warning(s) missed due to ratelimiting
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started System Logger Daemon "default" instance.
[  OK  ] Reached target Multi-User System.
Starting Sync Microchip PH…with PTP Grand Master Clock...
Starting Update UTMP about System Runlevel Changes...
[FAILED] Failed to start Sync Micro…C with PTP Grand Master Clock.
See 'systemctl status ptp4l.service' for details.
[  OK  ] Started Update UTMP about System Runlevel Changes.
[7.659157] ksz9477-switch 0-005f lan1: Link is Up - 1Gbps/Full - flow
control rx/tx

Poky (Yocto Project Reference Distro) 3.1.7 imx8mmevk ttymxc1

imx8mmevk login: [8.936988] bond1: (slave lan1): link status up,
enabling it in 0 ms
[8.943510] bond1: (slave lan1): link status definitely up, 1000 Mbps
full duplex
[8.951068] bond1: (slave lan1): making interface the new active one
[8.962012] device eth0 entered promiscuous mode
[8.966708] audit: type=1700 audit(1600598644.739:2): dev=eth0 prom=256
old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[8.966908] bond1: active interface up!
[8.985999] IPv6: ADDRCONF(NETDEV_CHANGE): bond1: link becomes ready

My ptp4l.service looks like:

cat ptp4l.service
[Unit]
Description=Sync Microchip PHC with PTP Grand Master Clock
Requires=network-online.target multi-user.target
BindsTo=sys-subsystem-net-devices-bond1.device
sys-subsystem-net-devices-lan1.device sys-subsystem-net-devices-lan2.device
multi-user.target
After=sys-subsystem-net-devices-bond1.device
sys-subsystem-net-devices-lan1.device sys-subsystem-net-devices-lan2.device
multi-user.target

[Service]
Type=exec
#NotifyAccess=all
ExecStart=/usr/bin/ptp4l -f /etc/linuxptp/ptp4l.conf_e2e_one_step_g8275.2
-s -i bond1
Restart=on-failure
RestartSec=1

[Install]
WantedBy=multi-user.target

In my .network file I specify that bond1 is required to for being "online":

root@imx8mmevk:/etc/systemd/network# cat 10-bond1.network
[Match]
Name=bond1

[Network]
#BindCarrier=eth0
DHCP=yes
#Address=192.168.0.4/24

[Link]
RequiredForOnline=yes

In .system file I tried all I know to ensure the required interfaces were
created before starting ptp4l in attempt to give bonding enough time to
finish but binding to things like sys-subsystem-net-devices-bond1.device
wasn't enough.

Is it also possible to use carrier state in .service file?

I see sys/devices/virtual/net/bond1/carrier but not sure how to only
attempt to start my ptp4l service a

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Run reboot as normal user

[Ulrich Windl]

>>> Martin Wilck  schrieb am 01.12.2021 um 10:41 in Nachricht
:
> On Wed, 2021‑12‑01 at 10:24 +0100, Ulrich Windl wrote:
>> > > 
>> 
>> And I wonder what's wrong with allowing the shutdown command for the
>> user in
>> sudoers.
>> (sudo $(which shutdown) ‑r now)
> 
> Sure. I thought sudo might not be installed on that embedded system,
> either. If it is, I'd prefer it over other solutions simply because
> it's more transparent. Capability bits tend to go unnoticed.
> 

Quote from OP: "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."

It was some odd security debate: If someone can operate as guest he/she should
not be able to reboot, while the guest user should be.
(Maybe I misunderstood. Any case some details for the problem are missing)


> Martin

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Run reboot as normal user

[Martin Wilck]

On Wed, 2021-12-01 at 10:24 +0100, Ulrich Windl wrote:
> > > 
> 
> And I wonder what's wrong with allowing the shutdown command for the
> user in
> sudoers.
> (sudo $(which shutdown) -r now)

Sure. I thought sudo might not be installed on that embedded system,
either. If it is, I'd prefer it over other solutions simply because
it's more transparent. Capability bits tend to go unnoticed.

Martin

[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Run reboot as normal user

[Ulrich Windl]

>>> Martin Wilck  schrieb am 01.12.2021 um 10:06 in Nachricht
:
> On Tue, 2021‑11‑30 at 14:11 +0100, Mohamed Ali Fodha wrote:
>> 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.
> 
> You could use setcap to set CAP_SYS_ADMIN capabilities on the
> executable you start for rebooting. I don't see a big difference wrt
> using AmbientCapabilities in a systemd service, as long as you restrict
> the program to be executable only by a certain user or group. Polkit
> can't do much more, either. Its main purpose is to serve logged‑in
> users that want to do certain priviliged actions like mount a volume or
> install software, and trigger pop‑ups that ask for either user or admin
> passwords. IIUC it's overengineered for what you're trying to do,
> unless you want to ask for a password or some other extra
> authorization.

And I wonder what's wrong with allowing the shutdown command for the user in
sudoers.
(sudo $(which shutdown) -r now)

> 
> OTOH, if you use CAP_SYS_ADMIN, you might as well use setuid. Same
> argument ‑ if you restrict the program properly, it comes down to
> exactly the same thing that polkit would do, just far simpler.
> 
> Martin

Re: [systemd-devel] Run reboot as normal user

[Martin Wilck]

On Tue, 2021-11-30 at 14:11 +0100, Mohamed Ali Fodha wrote:
> 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.

You could use setcap to set CAP_SYS_ADMIN capabilities on the
executable you start for rebooting. I don't see a big difference wrt
using AmbientCapabilities in a systemd service, as long as you restrict
the program to be executable only by a certain user or group. Polkit
can't do much more, either. Its main purpose is to serve logged-in
users that want to do certain priviliged actions like mount a volume or
install software, and trigger pop-ups that ask for either user or admin
passwords. IIUC it's overengineered for what you're trying to do,
unless you want to ask for a password or some other extra
authorization.

OTOH, if you use CAP_SYS_ADMIN, you might as well use setuid. Same
argument - if you restrict the program properly, it comes down to
exactly the same thing that polkit would do, just far simpler.

Martin