Re: systemd-devel Digest, Vol 155, Issue 13

["Lal, Arun" <arun.lal@xxxxxxxxx>]

Hi, 

Can someone help me in finding the right way to use polkit. 
So that dbus method calls can be made by non-root user to an dbus-interface of an application running in root. 

Right now method call fail in "check access" function. 

Regards,
Arun Lal K M

-----Original Message-----
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx
Sent: Wednesday, March 15, 2023 5:30 PM
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: systemd-devel Digest, Vol 155, Issue 13

Send systemd-devel mailing list submissions to
	systemd-devel@xxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
	systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
	systemd-devel-owner@xxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than "Re: Contents of systemd-devel digest..."


Today's Topics:

   1. Re:  systemd-devel Digest, Vol 155, Issue 8 (Lal, Arun)
   2. Re:  coredumpctl: matching by e.g. env var? (Luca Boccassi)
   3. Re:  coredumpctl: matching by e.g. env var? (Stephan Bergmann)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Mar 2023 09:51:30 +0000
From: "Lal, Arun" <arun.lal@xxxxxxxxx>
To: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re:  systemd-devel Digest, Vol 155, Issue 8
Message-ID:
	<DM4PR11MB5360A12FA03419289F0B31E588BF9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
	
Content-Type: text/plain; charset="utf-8"

Hi Lennart,

Adding to previous mail, to double confirm my understanding.

I have an application running in root which has an interface xyz.openbmc_project.CPU.GetData I have a non-root user called nonrootuser 

Right now systemd reject method call from nonrootuser to interface xyz.openbmc_project.CPU.GetData because of check_access function. 

As per you, we can add a polkit configuration to allow a nonrootuser to make method calls to interface xyz.openbmc_project.CPU.GetData. 

Is there anything wrong in my understanding?

Regards,
Arun Lal K M

-----Original Message-----
From: Lal, Arun
Sent: Wednesday, March 15, 2023 3:07 PM
To: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  systemd-devel Digest, Vol 155, Issue 8

Hi Lennart,

This makes lot of sense. ? 

The main objective I am looking for is to let the non-root user make a dbus-call to an application running in root. 
And as per your last mail it seems possible through polkit. Will it be possible for you to show me a reference to how this can be done using polkit? 

And from where can I learn how systemd code handles polkit configuration. Is there any documentation? 
It will also be good if you could give be a very high level brief on how polkit configuration allow/deny access to a user in making method calls. And which part of systemd code handles this. 

And let me clear up some confusion I created earlier.
- We can forget about caps discussion as it is not my main objective. It was something I thought could help, while going through code. 
And you have given me enough clarity on this ?

Regards,
Arun Lal K M

-----Original Message-----
From: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Sent: Monday, March 13, 2023 5:18 PM
To: Lal, Arun <arun.lal@xxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  systemd-devel Digest, Vol 155, Issue 8

On Sa, 11.03.23 08:29, Lal, Arun (arun.lal@xxxxxxxxx) wrote:

> 1) Dbus uses .conf files in /etc/dbus-1/system.d/ or /usr/share/dbus-1/system.d/ to allow and deny access to dbus method calls.
>     And what is the point of allowing a user in these conf files if
>     eventually systemd will block the call?

so, I think you are mixing up things. the caps thing is a red herring i guess.

We definitely support polkit in systemd. but it has nothing to do with caps.

dbus policy is mostly a useless concept, it's too static and riid. it nowadays has been largely supplanted by polkit: thus the low-level dbus policy for most services is just configured to be open, and the services use polkit to authenticate the calls and refuse them if polkit says no or cannot be reached.

> 2) Why is "busctl call" to slandered interfaces such as org.freedesktop.DBus.Peer still work even if caller is non-root.
>
> 3) I see that busctl commands such as "tree", "introspect" etc., are 
> still allowed for non-root user. So why is there a restriction "call"?

I don't understand that question.

method calls systemd#s services provide are usually protected by at least three levels: dbus policy (which as mentioned we mostly configure to be entirely open), polkit, and then selinux if that's available. Only if all three say "yes" we'll allow a call to go through.

In none of the three cases process capabilities come into the mix though, as mentioned in the other mail: we cannot use them for authenticating in userspace securely.

Lennart

--
Lennart Poettering, Berlin

------------------------------

Message: 2
Date: Wed, 15 Mar 2023 10:29:11 +0000
From: Luca Boccassi <luca.boccassi@xxxxxxxxx>
To: Stephan Bergmann <sbergman@xxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  coredumpctl: matching by e.g. env var?
Message-ID:
	<CAMw=ZnTEE+fNB0wQ3oTNy3X0CtCdRguqmLVHmVSdRLNwiWNo6Q@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"

On Wed, 15 Mar 2023 at 08:43, Stephan Bergmann <sbergman@xxxxxxxxxx> wrote:
>
> Hi all,
>
> I have a question about coredumpctl core dump matching, maybe somebody 
> has an idea:  The LibreOffice build system's `make check` machinery 
> has some logic to identify core files generated by crashed tests and 
> to use gdb to automatically obtain backtraces from them (similar to 
> `coredumpctl debug`; which is especially useful for builds running as 
> remote CI jobs, where all you get back is the build log including the 
> gdb backtraces).
>
> But that LibreOffice machinery relies on the traditional 
> /proc/sys/kernel/core_pattern=core setting.  For each test (which can 
> each spawn any number of sub-processes), it first cd's to a dedicated 
> per-test directory prior to starting the test, and then when the test 
> failed it invokes gdb on any core.* files found in that directory.
> Which worked quite well (hardly any test process would internally 
> establish a different cwd).
>
> Now, for environments using coredumpctl rather than the traditional 
> core_pattern, I'd like to make that machinery work too.  I'd need some 
> way to match exactly those core dumps coming from processes belonging 
> to a given test invocation.  (And many different tests use the same 
> test runner executable, which rules out matching by COREDUMP_EXE.)  I 
> find no journalctl match filter variable in systemd.journal-fields(7) 
> that looks like it could help me here.
>
> So one idea I had was whether it could be possible to match by a given 
> environment variable value?  The LibreOffice test machinery would set 
> some specific environment variable E to a (hopefully) unique per-test 
> value V prior to starting a test, and then when the test failed it 
> could query `coredumpctl debug` on matches of E=V.
>
> Any thoughts?

Use the elf metadata spec: https://systemd.io/ELF_PACKAGE_METADATA/

I need to update that, as these days it's no longer necessary to use a custom linker script, but with binutils 2.39 (or mold 1.3.0 or lld
15.0) it's as easy as passing as a linker flag:
--package-metadata='{"foo":"bar"}'
and it will be appended in the right location in the binary.
systemd-coredump will parse that, and attach it as-is as a COREDUMP_PACKAGE_JSON= field in the journal.
If the json contains fields named 'name' and/or 'version' they will also be appended independently as COREDUMP_PACKAGE_NAME= and COREDUMP_PACKAGE_VERSION=

You should be able to add your own identifier in the json and match on it easily.

Kind regards,
Luca Boccassi


------------------------------

Message: 3
Date: Wed, 15 Mar 2023 11:43:11 +0100
From: Stephan Bergmann <sbergman@xxxxxxxxxx>
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  coredumpctl: matching by e.g. env var?
Message-ID: <1f97bed7-c42c-85b8-5e19-9f654f25f827@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 15/03/2023 11:29, Luca Boccassi wrote:
> Use the elf metadata spec: https://systemd.io/ELF_PACKAGE_METADATA/
> 
> I need to update that, as these days it's no longer necessary to use a 
> custom linker script, but with binutils 2.39 (or mold 1.3.0 or lld
> 15.0) it's as easy as passing as a linker flag:
> --package-metadata='{"foo":"bar"}'
> and it will be appended in the right location in the binary.
> systemd-coredump will parse that, and attach it as-is as a 
> COREDUMP_PACKAGE_JSON= field in the journal.
> If the json contains fields named 'name' and/or 'version' they will 
> also be appended independently as COREDUMP_PACKAGE_NAME= and 
> COREDUMP_PACKAGE_VERSION=

But as I said "many different tests use the same test runner executable".  So I'm not sure how adding ELF metadata to some binary would help me in any way?  For example, two different tests recipes A and B each run python programs that each spawn a native soffice.bin process, where those soffice.bin processes don't include any .so that are specific to each test.  If test A fails, its recipe should dump backtraces for all core files caused by test A, but not for any core files caused by test B.



------------------------------

Subject: Digest Footer

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


------------------------------

End of systemd-devel Digest, Vol 155, Issue 13
**********************************************