On Wed, Dec 9, 2020 at 11:22 AM Topi Miettinen wrote:
>
> On 9.12.2020 17.14, Andy Lutomirski wrote:
> >
> Maybe also malware which can escape all means of detection, enforced by
> the CPU? Though I don't know if any malware scanners for Linux work can
> check for fileless, memory only malware.
On 9.12.2020 17.14, Andy Lutomirski wrote:
On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote:
On 9.12.2020 2.42, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
As a further argument, I
On Wed, 2020-12-09 at 10:50 +0100, Lennart Poettering wrote:
> Heya!
>
> Currently, some parts of the systemd tree link against OpenSSL, others
> link against gnutls and libgcrypt, and even others support either,
> controlled by a compile time switch.
>
> This is of course less than ideal, since
> On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote:
>
> On 9.12.2020 2.42, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, 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
On Mi, 09.12.20 10:55, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> > This is of course less than ideal, since it means we need to maintain
> > needlessly complex, redundant code to support this, it's not complete
> > (as not all combinations are supported), and footprint for general
>>> Lennart Poettering schrieb am 09.12.2020 um 10:50
in
Nachricht <20201209095057.GA30977@gardel-login>:
> Heya!
>
> Currently, some parts of the systemd tree link against OpenSSL, others
> link against gnutls and libgcrypt, and even others support either,
> controlled by a compile time switch.
Heya!
Currently, some parts of the systemd tree link against OpenSSL, others
link against gnutls and libgcrypt, and even others support either,
controlled by a compile time switch.
This is of course less than ideal, since it means we need to maintain
needlessly complex, redundant code to support
On 9.12.2020 2.42, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 02:15:28AM +0200, 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.
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 n
