Re: [systemd-devel] Systemd-cryptsetup triggers a black screen after upgrading to 6.4.1

2023-07-10 Thread Lennart Poettering
On Do, 06.07.23 18:07, Felix Rubio (fe...@kngnt.org) wrote:

> Using arch linux, I have had my kernel upgraded from 6.3.9 to 6.4.1. After
> regenerating the UKI, that works, I get just a black screen when
> systemd-cryptsetup should be either using the TPM to unlock the drive or to
> ask me the rescue password.

please provide boot logs, otherwise this is not actionable.

A black screen usually indicates some graphics problem. What makes you
think cryptsetup has anything to do with that?

Lennart

--
Lennart Poettering, Berlin


Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named

2023-07-10 Thread Marc Haber
On Mon, Jul 10, 2023 at 12:11:01PM +0200, Lennart Poettering wrote:
> ProtectHome= protects /home/, nothing else. Hence you can use it, and
> it should not collide with bind's use of the home dir, because it's
> not in /home.
> 
> Actually, correcting myself: use ReadOnlyBindPaths= for this. clients
> cann still connect to sockets on read-only fs just fine, but you take
> the privs away to chmod() or chown() the inode that way. So you get
> another line of defense that way.

Thank you, all my questions are answered for the time being. Your help
is appreciated.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named

2023-07-10 Thread Lennart Poettering
On Mo, 10.07.23 11:37, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> Hi Lennart,
>
> On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> > On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> >
> > > > It should suffice bind mounting just the notify socket, not the full
> > > > dir.
> > >
> > > Is it intended behavior that an empty file is left at the "mount point"
> > > (what Where= points to) after the unit was stopped?
> >
> > We need an inode we can overmount, and given that this is in /run/
> > (hence inherently ephemeral) and a fixed path it shouldn't matter.
>
> So this is intended. Good to know. I stumbled upon that.
>
> > > If I set ProtectHome=yes, how do I give the user that bind runs as
> > > access to its homedir? Is ReadWritePaths= the solution?
> >
> > ProtectHome= is about /home/ only, i.e. regular ("human") users, not
> > about system users (i.e. uid < 1K). Your bind should *not* run as
> > regular user, but as a system user of course, hence ProtectHome= is
> > something you can just set, and don't need to be concerned about the
> > system user's home dir.
>
> In Debian, bind runs as user bind, which gets created as a system user
> (uid < 1K, yes), and with /var/cache/bind as its home directory, which
> is the directory where, for example, slave zone files get written to.
> So, the running process needs to be able to access its "home directory"
> during its operation even after dropping root.

ProtectHome= protects /home/, nothing else. Hence you can use it, and
it should not collide with bind's use of the home dir, because it's
not in /home.

>
> > > [Mount]
> > > What=/run/systemd
> > > Where=/var/local/chroot/bind/run/systemd
> > > Type=none
> > > Options=bind
> >
> > Note that /run/ should always be a tmpfs, hence unless you mount a
> > tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.
> >
> > Instead of this .mount unit, consider using in the .service file:
> >
> > TemporaryFileSystem=/var/local/chroot/bind/run
> > BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify
>
> Ah, of course. I obviously didn't read BindPath's documentation
> thoroughly enough. That is of course way better. Thanks for helping me
> to read the docs.

Actually, correcting myself: use ReadOnlyBindPaths= for this. clients
cann still connect to sockets on read-only fs just fine, but you take
the privs away to chmod() or chown() the inode that way. So you get
another line of defense that way.

Lennart

--
Lennart Poettering, Berlin


Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named

2023-07-10 Thread Marc Haber
Hi Lennart,

On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> 
> > > It should suffice bind mounting just the notify socket, not the full
> > > dir.
> >
> > Is it intended behavior that an empty file is left at the "mount point"
> > (what Where= points to) after the unit was stopped?
> 
> We need an inode we can overmount, and given that this is in /run/
> (hence inherently ephemeral) and a fixed path it shouldn't matter.

So this is intended. Good to know. I stumbled upon that.

> > If I set ProtectHome=yes, how do I give the user that bind runs as
> > access to its homedir? Is ReadWritePaths= the solution?
> 
> ProtectHome= is about /home/ only, i.e. regular ("human") users, not
> about system users (i.e. uid < 1K). Your bind should *not* run as
> regular user, but as a system user of course, hence ProtectHome= is
> something you can just set, and don't need to be concerned about the
> system user's home dir.

In Debian, bind runs as user bind, which gets created as a system user
(uid < 1K, yes), and with /var/cache/bind as its home directory, which
is the directory where, for example, slave zone files get written to.
So, the running process needs to be able to access its "home directory"
during its operation even after dropping root.

> > [Mount]
> > What=/run/systemd
> > Where=/var/local/chroot/bind/run/systemd
> > Type=none
> > Options=bind
> 
> Note that /run/ should always be a tmpfs, hence unless you mount a
> tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.
> 
> Instead of this .mount unit, consider using in the .service file:
> 
> TemporaryFileSystem=/var/local/chroot/bind/run
> BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify

Ah, of course. I obviously didn't read BindPath's documentation
thoroughly enough. That is of course way better. Thanks for helping me
to read the docs.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named

2023-07-10 Thread Lennart Poettering
On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> > It should suffice bind mounting just the notify socket, not the full
> > dir.
>
> Is it intended behavior that an empty file is left at the "mount point"
> (what Where= points to) after the unit was stopped?

We need an inode we can overmount, and given that this is in /run/
(hence inherently ephemeral) and a fixed path it shouldn't matter.

> > You could also use a hybrid approach: let systemd bind mount this for
> > your service (and thus set up a minimal namespaced env for your
> > service, but with the root where it normally is), and then still let
> > bind do its own chroot() thing inside of it).
>
> I do not quite understand exactly what that means, how would I do that?
> What is "this" in the "mount this" part of sentence?

use BindPaths= to mount the notify socket to the right place.

> > Generally speaking: its typically a better idea to rely on proper fs
> > mount namespacing (i.e. decoupling mount tables of services and host)
> > rather than plain chroot() (where they aren't decoupled). If bind only
> > does chroot(), then I think using systemd's namespacing is the much
> > better choice.
>
> Where would I read up on systemd namespacing? Are you refering to what
> is explained in the "Sandboxing" chapter of systemd.exec(5), like
> ProtectSystem, ReadWritePaths etc?

yes.

> So I would basically set
> ProtectSystem=strict
> ReadWritePaths=/var/local/chroot/bind/pathlist (all paths that bind
> needs to actually write to) and then finally
> ExecStart=/path/to/bind -f -t /var/local/chroot/bind ?

I don't know bind, so can't judge on the command line, but otherwise, yeah.

> If I set ProtectHome=yes, how do I give the user that bind runs as
> access to its homedir? Is ReadWritePaths= the solution?

ProtectHome= is about /home/ only, i.e. regular ("human") users, not
about system users (i.e. uid < 1K). Your bind should *not* run as
regular user, but as a system user of course, hence ProtectHome= is
something you can just set, and don't need to be concerned about the
system user's home dir.

> > > This works as intended when I start up bind9, but when stopping the name
> > > daemon, the bind mount still lingers around. I have not fully understood
> > > the necessary systemd magic to have var-local-bind-run-systemd.mount
> > > stopped whenever bind9.service stops. How would I do that?
> >
> > You can do Wants= from bind to the mount unit. And then do
> > StopWhenUnneeded= in the mount unit, to release it when not needed.
>
> StopWhenUnneeded was what I needed. So I currently have:
>
> [7/5031]mh@drop:~ $ sudo systemctl cat named
> # /lib/systemd/system/named.service
> [Unit]
> Description=BIND Domain Name Server
> Documentation=man:named(8)
> After=network.target
> Wants=nss-lookup.target
> Before=nss-lookup.target
> RequiresMountsFor=/var/local/chroot/bind/run/systemd
>
> [Service]
> Type=notify
> EnvironmentFile=-/etc/default/named
> ExecStart=/usr/sbin/named -f $OPTIONS
> ExecReload=/usr/sbin/rndc reload
> ExecStop=/usr/sbin/rndc stop

bind doesn't react to SIGTERM correctly on its own?

> Restart=on-failure
>
> [Install]
> WantedBy=multi-user.target
> Alias=bind9.service
> [8/5030]mh@drop:~ $
>
> and
>
> 1 [9/5031]mh@drop:~ $ sudo systemctl cat 
> var-local-chroot-bind-run-systemd.mount
> # /etc/systemd/system/var-local-chroot-bind-run-systemd.mount
> [Unit]
> StopWhenUnneeded=true
>
> [Mount]
> What=/run/systemd
> Where=/var/local/chroot/bind/run/systemd
> Type=none
> Options=bind

Note that /run/ should always be a tmpfs, hence unless you mount a
tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.

Instead of this .mount unit, consider using in the .service file:

TemporaryFileSystem=/var/local/chroot/bind/run
BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify

(Under the assumption bind chroots itself into /var/local/chroot/bind)

Lennart

--
Lennart Poettering, Berlin