[systemd-devel] log_assert_failed_realm crash in systemd journal-file

[Aditya Tayade]

Hi,

I am getting below crash in our CI environment with systemd v244-stable
which looks similar to issue #14943
. So could you please
confirm if it is the same issue and whether the PR:
https://github.com/systemd/systemd/pull/15557 (already merged in v246) will
fix this? If yes then we need back port of these PR to v244-stable as well
and if not then could you please help to understand what can be cause of
this?:
(gdb) bt full
#0 __GI_abort () at abort.c:107
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0},
sa_mask = {__val = {
18446744073709551615 }}, sa_flags = 0, sa_restorer = 0x0}
sigs = {__val = {32, 0 }}
#1  0x007f87d2900c in
log_assert_failed_realm (realm=realm@entry=LOG_REALM_SYSTEMD,
text=text@entry=0x7f87d41f30 "p > 0",
file=file@entry=0x7f87d41e1f "src/journal/journal-file.c", line=line@entry
=2442,
func=func@entry=0x7f87d42fe0 <*PRETTY_FUNCTION*.13000> "test_object_seqnum")
at ../git/src/basic/log.c:809
No locals.
#2  0x007f87d0e5e8 in
test_object_seqnum (f=0x217c, p=0, needle=8572)
at ../git/src/journal/journal-file.c:2442
o =
r =
*PRETTY_FUNCTION* = "test_object_seqnum"
#3  test_object_seqnum
(f=f@entry=0x7f78012030,
p=p@entry=0, needle=needle@entry=8572)
at ../git/src/journal/journal-file.c:2437
o = 0x7f8524a0a8
r =
*PRETTY_FUNCTION* = "test_object_seqnum"
#4  0x007f87d0fa84 in
generic_array_bisect_plus_one (idx=0x0, offset=0x7f8524a210, ret=0x0,
direction=DIRECTION_DOWN, test_object=0x7f87d0e528 ,
needle=8572, n=1,
first=0, extra=0, f=0x7f78012030) at ../git/src/journal/journal-file.c:2376
r =
step_back =
o = 0x173318
r =
--Type for more, q to quit, c to continue without paging--
step_back =
o =
*PRETTY_FUNCTION* = "generic_array_bisect_plus_one"
#5 
generic_array_bisect_plus_one (f=0x7f78012030, extra=0, first=0, n=1,
needle=8572,
test_object=0x7f87d0e528 , direction=DIRECTION_DOWN,
ret=0x0,
offset=0x7f8524a210, idx=0x0) at ../git/src/journal/journal-file.c:2352
r =
o =
*PRETTY_FUNCTION* = "generic_array_bisect_plus_one"
#6  0x007f87d10f84 in
journal_file_move_to_entry_by_seqnum_for_data (f=f@entry=0x7f78012030,
data_offset=, seqnum=8572, direction=direction@entry=DIRECTION_DOWN,
ret=ret@entry=0x0, offset=offset@entry=0x7f8524a210) at
../git/src/basic/sparse-endian.h:83
d = 0x7f77a0cce8
r =
*PRETTY_FUNCTION* = "journal_file_move_to_entry_by_seqnum_for_data"
#7  0x007f87d15990 in
find_location_for_match (j=j@entry=0x7f78000bc0,
m=m@entry=0x7f78001fa0, f=f@entry=0x7f78012030, direction=direction@entry
=DIRECTION_DOWN,
ret=ret@entry=0x0, offset=offset@entry=0x7f8524a210) at
../git/src/journal/sd-journal.c:605
dp = 52456
r =
*PRETTY_FUNCTION* = "find_location_for_match"
#8  0x007f87d15838 in
find_location_for_match (j=j@entry=0x7f78000bc0,
m=m@entry=0x7f78001f50, f=f@entry=0x7f78012030, direction=direction@entry
=DIRECTION_DOWN,
ret=ret@entry=0x0, offset=offset@entry=0x7f8524a2a0) at
../git/src/journal/sd-journal.c:626
cp = 7161343769125990453
np = 0
n = 0x6362343731363035
--Type for more, q to quit, c to continue without paging--
i = 0x7f78001fa0
r =
*PRETTY_FUNCTION* = "find_location_for_match"
#9  0x007f87d156f8 in
find_location_for_match (j=j@entry=0x7f78000bc0,
m=m@entry=0x7f78001f00, f=f@entry=0x7f78012030, direction=direction@entry
=DIRECTION_DOWN,
ret=ret@entry=0x0, offset=offset@entry=0x7f8524a330) at
../git/src/journal/sd-journal.c:664
cp = 547474115520
i = 0x7f78001f50
np = 0
r =
*PRETTY_FUNCTION* = "find_location_for_match"
#10  0x007f87d15838 in
find_location_for_match (j=j@entry=0x7f78000bc0,
m=m@entry=0x7f78001eb0, f=f@entry=0x7f78012030, direction=direction@entry
=DIRECTION_DOWN,
ret=ret@entry=0x0, offset=offset@entry=0x7f8524a3c0) at
../git/src/journal/sd-journal.c:626
cp = 100
np = 0
n = 0xf4240
i = 0x7f78001f00
r =
*PRETTY_FUNCTION* = "find_location_for_match"
#11  0x007f87d156f8 in
find_location_for_match (j=j@entry=0x7f78000bc0, m=0x7f78001e60,
f=f@entry=0x7f78012030, direction=direction@entry=DIRECTION_DOWN,
ret=ret@entry=0x7f8524a478,
offset=offset@entry=0x7f8524a480) at ../git/src/journal/sd-journal.c:664
cp = 547694617584
i = 0x7f78001eb0
np = 0
r =
--Type for more, q to quit, c to continue without paging--
*PRETTY_FUNCTION* = "find_location_for_match"
#12  0x007f87d1725c in
find_location_with_matches (offset=0x7f8524a480, ret=0x7f8524a478,
direction=DIRECTION_DOWN, f=0x7f78012030, j=0x7f78000bc0)
at ../git/src/journal/sd-journal.c:709
r =
r =

[systemd-devel] systemd 244 version Execstop issue

[gowtham b]

Hi,

hope you are doing good
Facing issue in systemd 244 version Execstop is not executing while process
crashing. Did additional testing if we restart the process via systemd
"systemctl restart tr069pa" command Execstop is running properly seeing the
restart log in the redirected file. The same service file was used in
systemd 216 version not facing any issue in process crashing time Execstop
was executed properly. could please let me know if we have any known issues.

logs:
===
[Unit]
Description=Tr069Pa service

After=QandA.service
ConditionPathExists=!/tmp/disableTr069

[Service]
Type=forking
EnvironmentFile=/etc/device.properties
ExecStart=/usr/bin/Tr069Pa
ExecStop=/bin/sh -c 'echo "`date`: Stopping/Restarting Tr069Pa" >>
${PROCESS_RESTART_LOG}'
Restart=always

StandardOutput=syslog+console

2020 Dec 16 10:18:27  systemd[1]: Tr069Pa.service: Main process exited,
code=killed, status=11/SEGV
2020 Dec 16 10:18:27  systemd[1]: Tr069Pa.service: Failed with result
'signal'.
2020 Dec 16 10:18:37 systemd[1]: Tr069Pa.service: Scheduled restart job,
restart counter is at 1.
2020 Dec 16 10:18:37 systemd[1]: Stopped Tr069Pa service.
2020 Dec 16 10:18:37 systemd[1]: Starting Tr069Pa service...
2020 Dec 16 10:18:37 systemd[1]: Started Tr069Pa service.
=

Please let me know if any additional logs required.

Thanks,
Gowtham
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Lennart Poettering]

On Mo, 14.12.20 14:54, Adi Ml (maladi1...@gmail.com) wrote:

> Hi,
>
> I would like to harden my udev service with the
> SystemCallFilter option. What systemcalls should be permitted/allowed in
> order to secure it and avoid irrelevant system calls?

We apply system call filters to all long running services included in
systemd by default — but we don't for udev because we cannot. It's
more of an "application server" if you so will, that can run other
code, as people can drop in rules of any kind if they wish. And we
don't know what that'll be and what it wants to use. Hence we don't.

In specific setups that only supports very specific software you can
of course put together your own rules, but that's only something you
can do, if you know the stuff you run.

You may use "SystemCallLog=" (added in v247) in the udev unit file to
make the kernel log all system calls that are done by a service.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

[Topi Miettinen]

On 16.12.2020 12.03, Ulrich Windl wrote:

Jarkko Sakkinen  schrieb am 15.12.2020 um 05:19 in

Nachricht
<20201215041903.ga21...@kernel.org>:

On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:

Topi Miettinen  schrieb am 11.12.2020 um 12:46 in

Nachricht
<27796c04-249e-6cf0-c3e1-0fd657a82...@gmail.com>:

On 11.12.2020 12.46, Jarkko Sakkinen wrote:

On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:

On 9.12.2020 2.15, Jarkko Sakkinen wrote:

On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:

As  a further argument, I just did this on a Fedora system:
$ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
No results.  So making /dev noexec doesn't seem to have any

benefit.


It's no surprise that there aren't any executables in /dev since
removing MAKEDEV ages ago. That's not the issue, which is that
/dev is a writable directory (for UID=0 but no capabilities are
needed) and thus a potential location for constructing unapproved
executables if it is also mounted exec (W^X).


UID 0 can just change mount options, though, unless SELinux or

similar

is

used. And SELinux can protect /dev just fine without noexec.


Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also

SELinux

is not universal and the policies might not contain all users or

services.


‑Topi


What's the data that supports having noexec /dev anyway? With root
access I can then just use something else like /dev/shm mount.

Has there been out in the wild real world cases that noexec mount
of would have prevented?

For me this sounds a lot just something that "feels more secure"
without any measurable benefit. Can you prove me wrong?


I don't think security works that way. An attacker has various methods

to

choose from, some are more interesting than others. The case where

rw,exec

/dev would be interesting would imply that easier or more common

avenues

would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
/run/user/$UID/ for user. Also fileless malware with pure ROP/JOP

approach

with no need for any file system access is getting more common. It

does

not

mean that it would not be prudent to block the relatively easy

approaches

too, including /dev.


What if we add a new mount option "chrexec", which allows exec
for character devices (S_IFCHR).


I think devices are a bad match for SGX because devices haven't been
executable and SGX is actually an operation for memory. So something
like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
would be much more natural. Even better would be something that
conceptully also works for AMD version (either with the same flags or
MFD_SGX / MFD_whatever_the_AMD_version_is).


+1


SGX reserved memory from kernel's point of view is IO memory.

Mapping SGX to memfd would not be a great idea, as it does not map
into concept of anonymous file backed by regular memory.

A device file is very natural match actually. We have ioctl API for
uploading enclave pages during the build procedure to the enclave and
custom #PF handler. Conceptually it's a lot like video memory or such
special device specific memory area.

There's no AMD equivalent of this technology.


Hi!

Back to "noexec": AFAIR the execute bit does not make sense for device files,
and the purpose probably was to avoid execution of non-device files (e.g.
regular executables) from inside /dev (where they should not be). So in this
view "noexec" makes sense.
There were similar arguments for not allowing device files in user
directories.


PR#17940 (https://github.com/systemd/systemd/pull/17940) was merged, so 
/dev will now on be mounted with "exec" by systemd.


I made issue #17942 (https://github.com/systemd/systemd/issues/17942) to 
discuss related hardening options. I'm leaning towards 
NoExecPaths=/ExecPaths= as it would enable nice hardening by 
allow-listing of all executable content for system services with simple 
directives like:


[Service]
NoExecPaths=/
ExecPaths=/usr/sbin/daemon /lib64/ld-linux-x86-64.so.2 /usr/lib

Then a service infected with malware would not be able to execute a 
shell present in the system or downloaded later, if that was not 
explicitly allowed. /dev would also not have "exec" flag by default, but 
SGX could be allowed with "ExecPaths=/dev/sgx" when needed.


-Topi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

[Ulrich Windl]

>>> Jarkko Sakkinen  schrieb am 15.12.2020 um 05:19 in
Nachricht
<20201215041903.ga21...@kernel.org>:
> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
>> >>> Topi Miettinen  schrieb am 11.12.2020 um 12:46 in
>> Nachricht
>> <27796c04-249e-6cf0-c3e1-0fd657a82...@gmail.com>:
>> > On 11.12.2020 12.46, Jarkko Sakkinen wrote:
>> >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
>> >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
>>  On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>  As  a further argument, I just did this on a Fedora system:
>>  $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l
>>  No results.  So making /dev noexec doesn't seem to have any
benefit.
>> >>>
>> >>> It's no surprise that there aren't any executables in /dev since
>> >>> removing MAKEDEV ages ago. That's not the issue, which is that
>> >>> /dev is a writable directory (for UID=0 but no capabilities are
>> >>> needed) and thus a potential location for constructing unapproved
>> >>> executables if it is also mounted exec (W^X).
>> >>
>> >> UID 0 can just change mount options, though, unless SELinux or
similar
>> is 
>> > used. And SELinux can protect /dev just fine without noexec.
>> >
>> > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
>> SELinux
>> > is not universal and the policies might not contain all users or
>> services.
>> >
>> > ‑Topi
>> 
>>  What's the data that supports having noexec /dev anyway? With root
>>  access I can then just use something else like /dev/shm mount.
>> 
>>  Has there been out in the wild real world cases that noexec mount
>>  of would have prevented?
>> 
>>  For me this sounds a lot just something that "feels more secure"
>>  without any measurable benefit. Can you prove me wrong?
>> >>>
>> >>> I don't think security works that way. An attacker has various methods
to
>> >>> choose from, some are more interesting than others. The case where
>> rw,exec
>> >>> /dev would be interesting would imply that easier or more common
avenues
>> >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
>> >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
>> approach
>> >>> with no need for any file system access is getting more common. It
does
>> not
>> >>> mean that it would not be prudent to block the relatively easy
approaches
>> >>> too, including /dev.
>> >> 
>> >> What if we add a new mount option "chrexec", which allows exec
>> >> for character devices (S_IFCHR).
>> > 
>> > I think devices are a bad match for SGX because devices haven't been 
>> > executable and SGX is actually an operation for memory. So something 
>> > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX) 
>> > would be much more natural. Even better would be something that 
>> > conceptully also works for AMD version (either with the same flags or 
>> > MFD_SGX / MFD_whatever_the_AMD_version_is).
>> 
>> +1
> 
> SGX reserved memory from kernel's point of view is IO memory.
> 
> Mapping SGX to memfd would not be a great idea, as it does not map
> into concept of anonymous file backed by regular memory.
> 
> A device file is very natural match actually. We have ioctl API for
> uploading enclave pages during the build procedure to the enclave and
> custom #PF handler. Conceptually it's a lot like video memory or such
> special device specific memory area.
> 
> There's no AMD equivalent of this technology.

Hi!

Back to "noexec": AFAIR the execute bit does not make sense for device files,
and the purpose probably was to avoid execution of non-device files (e.g.
regular executables) from inside /dev (where they should not be). So in this
view "noexec" makes sense.
There were similar arguments for not allowing device files in user
directories.

Regards,
Ulrich

> 
> /Jarkko



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