On Sat, Sep 27, 2014 at 4:18 AM, Ric Moore <wayward4...@gmail.com> wrote: > On 09/26/2014 06:06 AM, Martin Steigerwald wrote: >> >> Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: >>> >>> On Vi, 26 sep 14, 01:58:44, lee wrote: >>>> >>>> Again, I consider it to be totally futile to try to convince the makers >>>> of systemd to fix the issues it brings about. They cannot be unaware of >>>> them, so obviously they don't want to fix them. I've seen for myself >>>> that they don't want to fix even little bugs which would be easy to fix >>>> from the bug report I made about their misunderstanding of what >>>> "disabled" means. >>> >>> >>> Could you please provide a link to that? >> >> >> Lee´s comments like this completely prove to me that Lee does not want any >> change from status quo. >> >> As he so far I read here refuses any and all suggestions to *act* towards >> change. I may have missed something here as I didn´t do myself the harm to >> read every post of every systemd related thread here, so if I did, mea >> culpa. >> >> But from what I read so far, Lee don´t want change. He prefers to put his >> energy into complaining about status quo instead. That leaves no energy >> for >> facilitating change.
The above is an argument about self-help attitudes. If you want change, you have to be willing to enable the changes you want by your choices, as well as support change by your actions. It's an argument that is only relevant on the list as a reminder to individual users that they (we) participate with the developers. > Change is certainly needed when And the argument from here is about a specific kind of change. Huge leap in logic. Leaps in logic can be enlightening, in some cases, not so much in other cases. > any pimple face kid can edit ... edit what? Be specific. I'm tempted to assume you mean ** system files ** or maybe just ** logs **, but you might be meaning ** their own pimple-faced files under their own pimple-faced login accounts ** . And why pimple-faced? Isn't that one of those expressions that falsely and disparagingly characterizes a group of individuals who may or may not have anything particular in common? Would it be that much worse to refer to skin color? But that isn't the biggest problem. If you do mean system files or logs or other people's settings, then the problem is not one that can or should be solved at pid 1. The problem, if not in the kernel and libraries, is in the system administrators refusing to do their jobs. > and hide his > doings from a text log with nano. Why nano? Why not hexedit? Or any of several tools a good sysadmin should be familiar with and not surprised by, should an intruder of any complexion, age, gender, race, or religion gain access to system resources he or she should not have access to. > I think the change is necessary to harden > up our systems. No, systemd just moves the problems, and actually makes the most intractable problems worse. You can't fix unfortunate kernel features or design at pid 1. You can't protect the system from bad system libraries at pid 1. If the kernel provides an intrusion path from user libraries, that's not something you can successfully stave off at pid 1. > Otherwise, Microsoft will become the only secure server OS, Get serious, ... > as they don't mind hiding things at all. ... the willingness to hide stuff is irrelevant to security. > Yes, it is a work in progress, but I think the main goal is signed binaries > that discourage the Black Hats But you are a black hat. In other words, it's essential for a sysadmin to assume the POV of a potential intruder to see the holes he or she is leaving in his or her walls, and it's just as essential for a sysdmin to recognize that he or she could well be the intruder, or in collusion with the intruders, if he or she fails to take the responsibility seriously. Talking about the Black Hats is yet another way of continuing the Us vs. Them arguments that basically ignore the real problems and keep the status quo. > ...at least for awhile. Whether you are referring to the escalation of cryptology or the inherent limits in systems, if you use those as an argument for improperly engineered pid 1 level attempts to plug the leaks, you might as well be in collusion with the "National Security" organizations and black market cartel organizations in the world. The problem is that the "new" features of systemd are things that cannot be safely done at pid 1. > What is telling is > that no one is talking about that. You're talking about it. Pretty much every conversation that promotes systemd starts with security issues as an assumption, if not specifying them directly. Which is very ironic. > Linux does indeed run the majority of the > web servers, so consider that if every major Linux Distro is working in > concert for a change, there has to be compelling reasons behind it, and that > we may not be privy to their reasonings for security's sake. If we can't read the code, we have problems. Linus himself told us that it is not safe to depend on him to warn us about intentional backdoors, but if we want to be able to get the warnings he and other developers want us to get, we have to be able to read the code. > The Net has > been proven to be as secure as Swiss Cheese lately, and that makes Linux > look very bad, if not half-assed. The essential nature of the net has not changed. That was why Microsoft's decision, in the mid-nineties, to start "enabling" their "Windows OSses" for the internet before they had properly secured both of them, and the repeated choice of features before security at the applications level was tantamount to criminal negligence. The fact that the monopoly suits ignored that negligences is evidence of either incompetence or collusion. I used to thing that the problem was judges and lawyers who didn't understand the tech. Groklaw was one of the things that taught me the reality: The industry itself was in collusion. And it still is. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ipxh644mzhaadcusby6xcpapk_3xyhr46mwttup_hk...@mail.gmail.com
