Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Martin Steigerwald]

Hi!

goli...@devuan.org - 02.05.21, 22:15:48 CEST:
> On 2021-05-02 06:08, terryc wrote:
> > Unfortunately there are systemd libraries installed by
> > Devuan-beowulf
> > desktop installation DVD.
> 
> [snip]
> 
> And they are harmless.
> 
> Why are systemd files present in Devuan?
> https://dev1galaxy.org/viewtopic.php?id=1925

No systemd library on my Devuan systems:

% dpkg -l | grep systemd
[no output]

Also none via locate.

Using Plasma as desktop together with elogind.

Best,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[golinux]

On 2021-05-02 06:08, terryc wrote:


Unfortunately there are systemd libraries installed by Devuan-beowulf
desktop installation DVD.




[snip]

And they are harmless.

Why are systemd files present in Devuan?
https://dev1galaxy.org/viewtopic.php?id=1925

golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Ludovic Bellière]

Hi terryc,

Those are *not* systemd libraries. They're services files or helpers
shipped with the various packages you install. It is not possible to get
rid of them without forking nearly all debian packages, which is beyond
the scope of the devuan project. The service files are text files and
benign.

Your system **is without** systemd.

Cheers,
Ludovic

On dim, 02 mai 2021, terryc wrote:

> On Sat, 1 May 2021 17:11:48 +0200
> Didier Kryn  wrote:
> 
> Unfortunately there are systemd libraries installed by Devuan-beowulf
> desktop installation DVD.
> 
> There are in
> /ver/lib/
> /lib
> /etc and
> /run
> 
> It appears to be something in the base system as both the headless
> systems I recently set up have/had* them.
> 
> Optins selected were
> console stuff
> print server,
> ssh server
> and what ever is last.
> 
> One system did have xfce-xfce4 selected, but the libraries and not
> dependant on these.
> 
> *rm -rf systemd on the relevant directories doesn't seem to affect
> anything. I did this as 'aptitude search systemd' didn't list any
> packages installed.
> 
> Memo to self; use minimal installation next time.


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Hopman (Was: ..are we|Devuan safe from this systemd backdoor malware (...)?

[aitor]

Hi Didier,

On 1/5/21 17:11, Didier Kryn wrote:

     Gvfs is not expected to be installed on servers, but is required by
some desktop goodies - even in Xfce4, for example if you install the
tool to mount/unmount hotplug disks; it is primarily to avoid it that I
developped hopman.
As i announced, i'm continuing your Hopman project and today i pushed 
the code of the new interface in Gtkmm-2.4,

keeping yours the same original folder GTK2. The code is available at:

https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/gtkmm 



There have been some changes in the watch directory too. For example, 
the original C code didn't manage removable
sata, ssd... hard disks connected via usb, because the integer storaged 
in the corresponding "removable" file [*] was equal to "0"
in such cases. On the other hand, trying to figure out how to get the 
hotplug partitioning data in the most efficient way,
i ended up involved in the helpers of vdev (stat_usb.* and common.* 
files in  the watch directory):


https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch 



I had wanted to upload the packages of hopman throughout the past week, 
but i've had issues related to some, already resolved,

GdkMouseEvents. Therefore, they'll be available as soon as posible.

Cheers,

Aitor.

[*] Have a look at the lines nº 25-30 of hotplug_partition.c:

https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch/hotplug_partition.c 



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[terryc]

On Sat, 1 May 2021 17:11:48 +0200
Didier Kryn  wrote:

> Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
> > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> > <20210430143720.7311bc82@d44>:
> >
> >  
> >> https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
> >>
> > ..how it works:
> > https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/  
> 
> 
>     This backdoor is targetting systemd and gvfs.
> 
>     It is not very surprising that systemd is targetted, since it is
> present (by force) in most installed Linux systems.

Unfortunately there are systemd libraries installed by Devuan-beowulf
desktop installation DVD.

There are in
/ver/lib/
/lib
/etc and
/run

It appears to be something in the base system as both the headless
systems I recently set up have/had* them.

Optins selected were
console stuff
print server,
ssh server
and what ever is last.

One system did have xfce-xfce4 selected, but the libraries and not
dependant on these.

*rm -rf systemd on the relevant directories doesn't seem to affect
anything. I did this as 'aptitude search systemd' didn't list any
packages installed.

Memo to self; use minimal installation next time.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Didier Kryn]

Le 01/05/2021 à 17:50, Florian Zieboll via Dng a écrit :
> Hallo Didier,
>
> why do you think it's targeting only systems with systemd or gvfs
> installed? At a first glance, I don't see any hints towards this
> conclusion besides the fact that the installer / dropper of this very
> sample did name the executables accordingly and provides a systemd
> "service" file. It should be easily realizable to automatically choose
> other names, depending on the targeted environment.
>
> The Netlab blog post even states:
>
> ||  Depending on the Linux distribution, create the corresponding
> ||  self-starting script /etc/init/systemd-agent.conf
> ||  or /lib/systemd/system/sys-temd-agent.service.
>
> AFAIK, the directory '/etc/init/' is only created/used by resp. for the
> 'upstart' init system, thus I assume that also (at least) those systems
> are covered as well.

    Apparently I overlooked it a bit, however, if neither systemd nor
gvfs are explicitely targetted, systems running these softwares are. If
the executables are named systemd-daemon and gvfsd, it's for the process
names to be the same and not alarm the admin.

    If I discovered on one of  my Devuan machines a process named
systemd-what-the-f or gvfs-something, I would immediately kill it and
try to find where it comes from. But if I was running Gnome on Debian, I
certainly wouldn't.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng