I post this in the networking section because it seems auditing/debugging SystemD is not really done for it is too complex. On the network it suppose to show up if there is some kind of backdoor in SystemD.
Yes i am a linux user. My clients and my servers run on various linux flawors. I am not that deep into linux for me to be able to say much about it. I work on thrust.... i know maybe i should hire a bunch of BSD guys (and girls).
No not a flaw... Did anybody here find ANY prove of a backdoor? Or yes it would be a flaw....
I realize it is a bit of a retarded question... one would not need a backdoor to brake into a system. Maybe i am asking if there are automated systems that sneaky suck out the private data of your linux server. Or otherwise.
I guess if there were nobody who knows about it would be here to answer me (us).
Consider this thread dead and newb. :-) i still have to wake up.. its early
Perhaps you could expand a bit on the underlying concern you have which motivated this particular sentence. I am very interested in particulars.
If I have suspicions about what may be going on with my own local area network, early on I run a port scan using nmap. It provides a per-machine listing of open ports and what may be running on them. In this context, suspicion about a "backdoor" would arise from unexpectedly open ports or ports running unexpected things. Other folk would audit their network in a different manner, I suppose. The key thing is, have you done such a quick survey, using nmap or something of that ilk, and have specific suspicions centered on a machine that is running systemd, suspicions, perhaps, on how systemd impinges on the network stack?
Systemd impinges on many aspects of Linux, in ways that cross what some people hold as best practices. As a consequence, much has been written about systemd, lots of it passionate, and some of it may even be true. If you understand my poor attempt at mordant humor, then investigate the motivations behind whatever is said or written about systemd, especially about back doors, then do your own tests. I write this neither as a fan nor as a detractor of systemd; I've deployed it one machine out of a dozen in the last two years. During that time, I've not observed anything about systemd that looks like a back door. That said, in the fullness of time I'll retire its use on the one machine - not for any particular badness; it's implementation just doesn't suit my taste. I find it ambitious, unrestrained, and the interactions between it and other things are complex and, I think, difficult to debug. Difficult, for example, to prove - or disprove - the existence of a purported network backdoor. Sadly, much the same can also be said about other system initialization frameworks - it's the nature of the beast. But I digress ;).
There are plenty of reasons systemd is terrible outside of tinfoil ( non-transparent, obfuscated logging, requiring pulls from otherwise agnostic projects, etc.)
A vanishingly small possibility of a backdoor is the least of it's problems
If you're fine with it's day-to-day BS, then there's no huge incentive to switch to something else (read: something better and more sane)