Perhaps it is the idea that a linux machine should be wholly modular and attaching a library to a critical component of the system, shouldn't be a viable strategy for popularizing one's work.
When a distro is forced to carry a package due to a dependency of a dependency, or any magnitude there of, it breaks a core separation of power there. The users depend on distro's to provide reliable packages, however if a package is intentionally interweaving files to make these dependencies simply a part of the file and therefore robbing the distro's the ability to choose a different dependency should another developer or team thereof prove more reliable or more suited for their distro.
Systemd in this sense would be like microsoft robbing those wishing to distinguish themselves of the ability by increasing the magnitude of difficulty in doing so.
Now, keep in mind, I am not fluent in any programming language and have not audited Systemd, nor do I know anyone who has. This is based on a compiled understanding of observations expressed in arguments both infavor and against Systemd.
2017-02-15 7:30 GMT+01:00 John Luke Gibson eaterjolly@gmail.com:
Perhaps it is the idea that a linux machine should be wholly modular and attaching a library to a critical component of the system, shouldn't be a viable strategy for popularizing one's work.
True
When a distro is forced to carry a package due to a dependency of a dependency, or any magnitude there of, it breaks a core separation of power there. The users depend on distro's to provide reliable packages, however if a package is intentionally interweaving files to make these dependencies simply a part of the file and therefore robbing the distro's the ability to choose a different dependency should another developer or team thereof prove more reliable or more suited for their distro.
It's not really about "files". It's about functionality.
The reason for an "init" system is automation. In order to have a "functional " desktop a log of services need to be running.
Different functionality requirements require different "init" systems. So in order for software to support all different "init" systems you need to go an extra mile which not every maintainers is willing to do.
So for distro's to support multiple "init" systems they need to modify/enhance software from others. And they need to test all possible configurations. Which is extra effort not everyone is willing to do.
Systemd in this sense would be like microsoft robbing those wishing to distinguish themselves of the ability by increasing the magnitude of difficulty in doing so.
If I read the discomfort correctly the systemd maintainers are too focused on their own use case and seek to little collaboration with the rest of the community during development.
This results in issues for people with "corner" cases, which don't get resolved. And massive code dumps which result in massive rewrites too get support from the rest of the community.
This is indeed quite similar to a closed source business like Microsoft. The company sets their goals and developers need to follow the goals set by the company. Not the goals set by others or what might even be a beter goal for the user.
I think in the end, the one that pays decides. To change code you need time. That time needs to be paid. Individual developers can donate time they have left after earning that by other work. Company's can donate time of employees. But the time spent must be paid, either by other work or by the result of the donated time. Usually it is the latter so that's why company's decide where time is spent within a project.
But for a OS project to be successful you need to consider the needs of others so it's a balancing act.
Now, keep in mind, I am not fluent in any programming language and have not audited Systemd, nor do I know anyone who has. This is based on a compiled understanding of observations expressed in arguments both infavor and against Systemd.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
John Luke Gibson eaterjolly@gmail.com writes:
Perhaps it is the idea that a linux machine should be wholly modular and attaching a library to a critical component of the system, shouldn't be a viable strategy for popularizing one's work.
When a distro is forced to carry a package due to a dependency of a dependency, or any magnitude there of, it breaks a core separation of power there. The users depend on distro's to provide reliable packages, however if a package is intentionally interweaving files to make these dependencies simply a part of the file and therefore robbing the distro's the ability to choose a different dependency should another developer or team thereof prove more reliable or more suited for their distro.
Systemd in this sense would be like microsoft robbing those wishing to distinguish themselves of the ability by increasing the magnitude of difficulty in doing so.
Now, keep in mind, I am not fluent in any programming language and have not audited Systemd, nor do I know anyone who has. This is based on a compiled understanding of observations expressed in arguments both infavor and against Systemd.
Which is why it does not actually add anything, sadly.
In Debian we've made sure that one can run without systemd (the init replacement) as init. We actually have support for non-linux kernels, which therefore do not support systemd, which is not portable, so chances are that Debian will continue to support systems that do not have systemd as init.
Under the umbrella of systemd (the project) one finds other separate components such as journald and loggind. These are separate components that one could individually replace if there were viable alternatives. They are separate in the traditional unix-like, do one thing well style that people complain about systemd not following.
One set of alternatives to these components used to be mostly provided by the various Kits, like ConsoleKit which does pretty much the same thing as loggind.
These alternatives have mostly rotted on the vine since the systemd efforts turned up. Blaming systemd for providing software that is better, to the extent that people switch away from the previously available components, does not strike me as overly reasonable.
People that care about the lack of alternatives probably ought to start doing something about that, instead of complaining about it.
It is not worthwhile to expect people that work on (or who prefer) systemd to also work on those alternatives that they do not use.
As it happens, the Debian systemd folk went beyond the call of duty by coming up with the systemd-shim package, which makes it more easily possible to avoid systemd as init. Understanably they are not particularly motivated to carry maintenance for that forever, and sadly nobody else seems moved to step forward. So that package is currently orphaned, waiting for a maintainer to pick it up.
Of course, once the likes of ConsoleKit have rotted, the modern desktops are left with little alternative but relying on logind to provide this functionality, at which point the popular distros end up with an implicit dependency on at least some components provided by the systemd project.
That still is not a hard dependency on systemd-the-init-running-as-PID-1
It is also not something that was forced on anyone.
Most distros have decided that maintaining the option to run other inits is really not worth the effort, since there's not much benefit, and certainly it introduces bugs one didn't need to experience.
I hope I've got that at least broadly right, since I'm neither a systemd enthusiast, nor a systemd hater.
My own systems are generally set up to need me to run sudo mount rather than having ConsoleKit/logind determine that I'm logged in, and so can do that by clicking something, so I'm not really the target audience of GUI users that need all these extra components (which are part of systemd the project, but sod all to do with what I might run as init)
Having people confuse systemd the project with systemd the init, and the running of the init as a normal user process with running it as PID1, and then insisting that getting rid of libsystemd0 is important for some reason, makes the water so muddy that anyone that's been paying attention to this subject for any time at all is _very_ bored by it by now.
Can we stop please?
Cheers, Phil.
I appreciate the explanation. My premise was based on the linux sucks video sequel which argued that many people thought systemd was messy because it wasn't minimalist enough.
If the code of the init system is not getting expanded by interweaving component files, that leaves me curious what it is getting expanded by. I presume that might be extra firmware for more support of more hardware, but idk.
Anyways, I can see this topic is tiring so readers hereof need not respond to this thread :P
On 2/15/17, Philip Hands phil@hands.com wrote:
John Luke Gibson eaterjolly@gmail.com writes:
Perhaps it is the idea that a linux machine should be wholly modular and attaching a library to a critical component of the system, shouldn't be a viable strategy for popularizing one's work.
When a distro is forced to carry a package due to a dependency of a dependency, or any magnitude there of, it breaks a core separation of power there. The users depend on distro's to provide reliable packages, however if a package is intentionally interweaving files to make these dependencies simply a part of the file and therefore robbing the distro's the ability to choose a different dependency should another developer or team thereof prove more reliable or more suited for their distro.
Systemd in this sense would be like microsoft robbing those wishing to distinguish themselves of the ability by increasing the magnitude of difficulty in doing so.
Now, keep in mind, I am not fluent in any programming language and have not audited Systemd, nor do I know anyone who has. This is based on a compiled understanding of observations expressed in arguments both infavor and against Systemd.
Which is why it does not actually add anything, sadly.
In Debian we've made sure that one can run without systemd (the init replacement) as init. We actually have support for non-linux kernels, which therefore do not support systemd, which is not portable, so chances are that Debian will continue to support systems that do not have systemd as init.
Under the umbrella of systemd (the project) one finds other separate components such as journald and loggind. These are separate components that one could individually replace if there were viable alternatives. They are separate in the traditional unix-like, do one thing well style that people complain about systemd not following.
One set of alternatives to these components used to be mostly provided by the various Kits, like ConsoleKit which does pretty much the same thing as loggind.
These alternatives have mostly rotted on the vine since the systemd efforts turned up. Blaming systemd for providing software that is better, to the extent that people switch away from the previously available components, does not strike me as overly reasonable.
People that care about the lack of alternatives probably ought to start doing something about that, instead of complaining about it.
It is not worthwhile to expect people that work on (or who prefer) systemd to also work on those alternatives that they do not use.
As it happens, the Debian systemd folk went beyond the call of duty by coming up with the systemd-shim package, which makes it more easily possible to avoid systemd as init. Understanably they are not particularly motivated to carry maintenance for that forever, and sadly nobody else seems moved to step forward. So that package is currently orphaned, waiting for a maintainer to pick it up.
Of course, once the likes of ConsoleKit have rotted, the modern desktops are left with little alternative but relying on logind to provide this functionality, at which point the popular distros end up with an implicit dependency on at least some components provided by the systemd project.
That still is not a hard dependency on systemd-the-init-running-as-PID-1
It is also not something that was forced on anyone.
Most distros have decided that maintaining the option to run other inits is really not worth the effort, since there's not much benefit, and certainly it introduces bugs one didn't need to experience.
I hope I've got that at least broadly right, since I'm neither a systemd enthusiast, nor a systemd hater.
My own systems are generally set up to need me to run sudo mount rather than having ConsoleKit/logind determine that I'm logged in, and so can do that by clicking something, so I'm not really the target audience of GUI users that need all these extra components (which are part of systemd the project, but sod all to do with what I might run as init)
Having people confuse systemd the project with systemd the init, and the running of the init as a normal user process with running it as PID1, and then insisting that getting rid of libsystemd0 is important for some reason, makes the water so muddy that anyone that's been paying attention to this subject for any time at all is _very_ bored by it by now.
Can we stop please?
Cheers, Phil.
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
On Wed, Feb 15, 2017 at 9:29 PM, John Luke Gibson eaterjolly@gmail.com wrote:
I appreciate the explanation. My premise was based on the linux sucks video sequel which argued that many people thought systemd was messy because it wasn't minimalist enough.
If the code of the init system is not getting expanded by interweaving component files, that leaves me curious what it is getting expanded by. I presume that might be extra firmware for more support of more hardware, but idk.
the scope creep is what has people who have security knowledge deeply concerned. expansion into management of network firewall rules, ability to kill and spawn processes (all this is in PID 1) - and it's *in development* rather than having been declared under a roadmap many years ago.
they've violated ISO 9001 so many times that far from being able to trust the developers of systemd to rein in their continued expansion, the *complete opposite* is the case.
for a good indication of the extent of the problem, you can look at the SE/Linux permissions for systemd. it will be... worryingly extensive.
the FLASK model was designed based around the principle of "no permissions unless necessary". it's fully recognised that executables (exec) is the only safe way to ensure a boundary. fork is clearly not ok: it allows memory, as well as file handles, to be shared between processes.
so the only way to gain additional privileges would be to run a *SEPARATE* executable (which is again a controlled operation) using a tuple:
* name of executable currently running * user-context (or equivalent in SE/Linux) * name of executable to be exec'd (note: NOT forked. fork carries over too much to be trusted) * new user-context (equivalent thereof) under which executable is to be run
within the new user-context, an ENTIRELY SEPARATE set of permissions is associated. a good way to think of this is for a 5 star general to go to a NATO army base. at the gate, the 5 star general's Military ID is *TAKEN AWAY* just like everyone else's and is replaced with a badge. he gets his ID back (just like anyone else) when he leaves the base.
on the replacement badge it is coded with time, date and the *specific* doors that he is allowed to open with it, as scheduled per his visit... just like everyone else.
if he tries to leave the base without his Military ID, he can't get on the plane to get back to the USA. doesn't matter that he's a 5 star general.
this is exactly how SE/Linux works.
systemd doesn't violate SE/Linux "per se" but it violates the *principle* for which SE/Linux was designed (to restrict attack vectors), by demanding - in a single process - so many permissions that you might as well not even bother *running* SE/Linux in the first place.
it seems that there are very few people in the linux community who actually understand this - that trusting systemd to manage so much is *really* dangerous, particularly given the track record of the systemd developers. no, having separate processes (such as logind) which manage certain aspects via a d-bus (or other) network interface is not an answer, if it's managed by something that's been totally compromised it allows the components it's *communicating* with to be compromised as well.
i don't explain this stuff to people because i expect them to know it. i thought it wasn't my role to explain it to people, because i'm now focussing on hardware design, not security analysis and threat assessment: i haven't dealt with that stuff in almost 15 years now.
l.
On 02/15/2017 05:12 PM, Luke Kenneth Casson Leighton wrote:
On Wed, Feb 15, 2017 at 9:29 PM, John Luke Gibson eaterjolly@gmail.com wrote:
I appreciate the explanation. My premise was based on the linux sucks video sequel which argued that many people thought systemd was messy because it wasn't minimalist enough.
If the code of the init system is not getting expanded by interweaving component files, that leaves me curious what it is getting expanded by. I presume that might be extra firmware for more support of more hardware, but idk.
the scope creep is what has people who have security knowledge deeply concerned. expansion into management of network firewall rules, ability to kill and spawn processes (all this is in PID 1) - and it's *in development* rather than having been declared under a roadmap many years ago.
they've violated ISO 9001 so many times that far from being able to trust the developers of systemd to rein in their continued expansion, the *complete opposite* is the case.
for a good indication of the extent of the problem, you can look at the SE/Linux permissions for systemd. it will be... worryingly extensive.
the FLASK model was designed based around the principle of "no permissions unless necessary". it's fully recognised that executables (exec) is the only safe way to ensure a boundary. fork is clearly not ok: it allows memory, as well as file handles, to be shared between processes.
so the only way to gain additional privileges would be to run a *SEPARATE* executable (which is again a controlled operation) using a tuple:
- name of executable currently running
- user-context (or equivalent in SE/Linux)
- name of executable to be exec'd (note: NOT forked. fork carries
over too much to be trusted)
- new user-context (equivalent thereof) under which executable is to be run
within the new user-context, an ENTIRELY SEPARATE set of permissions is associated. a good way to think of this is for a 5 star general to go to a NATO army base. at the gate, the 5 star general's Military ID is *TAKEN AWAY* just like everyone else's and is replaced with a badge. he gets his ID back (just like anyone else) when he leaves the base.
on the replacement badge it is coded with time, date and the *specific* doors that he is allowed to open with it, as scheduled per his visit... just like everyone else.
if he tries to leave the base without his Military ID, he can't get on the plane to get back to the USA. doesn't matter that he's a 5 star general.
this is exactly how SE/Linux works.
systemd doesn't violate SE/Linux "per se" but it violates the *principle* for which SE/Linux was designed (to restrict attack vectors), by demanding - in a single process - so many permissions that you might as well not even bother *running* SE/Linux in the first place.
it seems that there are very few people in the linux community who actually understand this - that trusting systemd to manage so much is *really* dangerous, particularly given the track record of the systemd developers. no, having separate processes (such as logind) which manage certain aspects via a d-bus (or other) network interface is not an answer, if it's managed by something that's been totally compromised it allows the components it's *communicating* with to be compromised as well.
i don't explain this stuff to people because i expect them to know it. i thought it wasn't my role to explain it to people, because i'm now focussing on hardware design, not security analysis and threat assessment: i haven't dealt with that stuff in almost 15 years now.
Very insightful, never knew that selinux and systemd had such compatiblity issues when used together...
gufw probably has similiar issues I am guessing...
Yeah... I am beginning to agree. if you cannot restrict attack vectors when systemd is in the system then there is a problem. and I have a feeling there are more issues unknown lurking underneath the surface that have yet to be revealed. Thanks for enlightening me Luke.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, Feb 15, 2017 at 10:25 PM, zap zapper@openmailbox.org wrote:
Very insightful,
thx. i just... don't explain this stuff very much any more as i expect people to know it. also, i didn't (and still don't) get paid for the expertise i'm aware of, so don't have an established reputation where people would actually *listen*.... so i remain silent instead.
never knew that selinux and systemd had such compatiblity issues when used together...
correction of possible misunderstanding: systemd is just "an executable" (or set thereof). selinux is: "a system for monitoring *and specifying* in a formal language the permitted behaviour and interaction *of* executables". you can just as equally well drop selinux on top of sysvinit scripts, and anything else, all the way down to individual X11 system calls if you really want to. it just takes a hell of a long time to work out useful selinux privileges, so most people don't bother.
caveat: i haven't done the expansion of the macros myself in order to do a full analysis (because i don't use selinux any more) - simply haven't got time. i'm pointing out that anyone who *wants* to can do so (and confirm what i'm saying). the whole reason why SE/Linux was invented was so as to be *able* to do mathematical proofs on the security of a system (from the underlying FLASK model). but from what i know of systemd, i *know* that anyone who does so will be in for a huge shock.
gufw probably has similiar issues I am guessing...
Yeah... I am beginning to agree. if you cannot restrict attack vectors when systemd is in the system then there is a problem. and I have a feeling there are more issues unknown lurking underneath the surface that have yet to be revealed. Thanks for enlightening me Luke.
the NSA's nightmare (or, any intelligence community) is not what you *know* to be insecure: if you know something's insecure you can put monitoring, resources or appropriate mitigation strategies in place. it's what you *don't* know to be secure (or insecure) that's the nightmare, because you have to assume the absolute worse-case, and that eats both time and resources. if they don't *know* then they've completely failed at their job, basically.
that's fundamentally what SE/Linux was designed for: to be able to *formally* say, "we know X is secure and Y isn't because here's a formal mathematical proof of it: X isn't permitted network access, Y demands waay too many privileges to be secure". and *now* you can do a proper risk assessment.
if systemd is so bloated and all-encompassing that it in effect demands *all* privileges (it doesn't, but you know what i mean), it utterly defeats the object of having the security system in the first place.
or, more to the point: a program which demands such extreme privileges *is* by definition completely untrustable. a bit like those android apps that demand "full access", basically. you *know* it's going to be downhill from that point onwards.
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
if systemd is so bloated and all-encompassing that it in effect demands *all* privileges (it doesn't, but you know what i mean), it utterly defeats the object of having the security system in the first place.
This appears to be another instance of you conflating the init process with the project, but perhaps I'm misunderstanding you.
Are you claiming that systemd (the init) uses forks where sysvinit uses execs?
Surely in order to use exec as an init, one must first fork in order to avoid no longer having an init process, so what exactly are you trying to say here? Does systemd fork all its subordinate processes?
A very quick glance at the source reveals this:
http://sources.debian.net/src/systemd/232-18/CODING_STYLE/?hl=342#L342
which suggests that they are at least generally intending to avoid what you're talking about.
Perhaps you can cite some examples where they've failed in that quest.
Cheers, Phil.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Feb 16, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
if systemd is so bloated and all-encompassing that it in effect demands *all* privileges (it doesn't, but you know what i mean), it utterly defeats the object of having the security system in the first place.
This appears to be another instance of you conflating the init process with the project, but perhaps I'm misunderstanding you.
Are you claiming that systemd (the init) uses forks where sysvinit uses execs?
i don't know how you conclude i would say that when i don't mention sysvinit. why would there be an implication of sysvinit being involved when it's not mentioned?
i'm saying that SE/Linux's security model is based on the isolation of exec. but, that if the sheer overwhelming number of programs being exec'd is so huge, it becomes pretty pointless to even *have* such isolation.
i provide this as a guide *without* spending the time to assess actual instances... because it's not my job to do so. and, also, with the sheer overwhelming number of *other* factors (all of them individually low-probability events), when combined using demster-shafer information theory, you don't *need* to go in-depth: to do so is completely pointless.
basically i'm saying, phil, knocking down one skittle by spending the time to track down one "hole" in what i say, is pointless. the entire design and deployment of systemd is like a dam made of swiss cheese.
there simply aren't enough fingers to plug all the hundreds of flaws... so there's little point in trying. this response (one of a long line of reasons why i will never *ever* use systemd) is just one response from a different angle, one that i have had at least one person publicly express gratitude for taking the time to explain, and one privately. who knows well enough and is old enough and ugly enough *not* to get involved in the cluster-fuck known as systemd.
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Feb 16, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
if systemd is so bloated and all-encompassing that it in effect demands *all* privileges (it doesn't, but you know what i mean), it utterly defeats the object of having the security system in the first place.
This appears to be another instance of you conflating the init process with the project, but perhaps I'm misunderstanding you.
Are you claiming that systemd (the init) uses forks where sysvinit uses execs?
i don't know how you conclude i would say that when i don't mention sysvinit. why would there be an implication of sysvinit being involved when it's not mentioned?
Well, if you're saying that systemd is bad, it must be bad relative to something else since if the nearest likely alternative e.g. sysvinit does pretty-much the same thing then you're really saying very little.
The Daily Mail will cheerfully tell you that Coffee causes cancer, which is probably true, but only at about the same rate as pretty much everything else one could imagine consuming, so ... no news.
i'm saying that SE/Linux's security model is based on the isolation of exec. but, that if the sheer overwhelming number of programs being exec'd is so huge, it becomes pretty pointless to even *have* such isolation.
Systemd execs a lot of things by dint of it being the system's init, does it not? This sounds almost like you're claiming that SElinux isn't capable of modeling any implementation of the init task.
That's why I was trying to tease out something about what makes this unique to sytemd from you. Hence the mention of sysvinit.
i provide this as a guide *without* spending the time to assess actual instances... because it's not my job to do so. and, also, with the sheer overwhelming number of *other* factors (all of them individually low-probability events), when combined using demster-shafer information theory, you don't *need* to go in-depth: to do so is completely pointless.
basically i'm saying, phil, knocking down one skittle by spending the time to track down one "hole" in what i say, is pointless. the entire design and deployment of systemd is like a dam made of swiss cheese.
there simply aren't enough fingers to plug all the hundreds of flaws... so there's little point in trying. this response (one of a long line of reasons why i will never *ever* use systemd) is just one response from a different angle, one that i have had at least one person publicly express gratitude for taking the time to explain, and one privately. who knows well enough and is old enough and ugly enough *not* to get involved in the cluster-fuck known as systemd.
I'm not trying to knock down skittles -- I'm trying to see whether what you're saying has any substance behind it, or is simply hand waving.
Cheers, Phil.
On Thu, Feb 16, 2017 at 11:06 AM, Philip Hands phil@hands.com wrote:
On Thu, Feb 16, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
I'm not trying to knock down skittles -- I'm trying to see whether what you're saying has any substance behind it, or is simply hand waving.
one of the things that i am learning - 47 in a week's time - is that it's best if i mention some things - some clues - then let people work out the details. usually the topic that i pick is sufficiently controversial to others (for example, taking on intel. or microsoft) that it freaks people out and they unfortunately *automatically* become defensive... or look for ways to dismiss what i'm saying.
with my "detection" system being such a semi-accurate parallel "breadth first, multiple independent sources confirmation" one instead of "depth-first, accurate detais" as is the case with so many other people (including you, phil), there is *no point* in me trying to answer your question.
(a) i will get the details wrong. this will only lessen the value of the discussion. (b) you will consider the assessment to be so low risk as to be worthless evaluating (c) by the time we've gone through even *three* of the [at least fifteen in this case] multiple independent sources, you'll be driven *so up the wall* that it becomes counter-productive to continue.
in each and every case, you will ONE HUNDRED PERCENT conclude that there is, far from being ANY value to what i'm saying, that EVERYTHING i am saying demonstrates one hundred percent THE OPPOSITE.
(a) no accurate details. (b) zero risk (c) pointless continuing to discuss further
now. knowing that, i really cannot answer your question knowing that even attempting to do so would result in you concluding that the assessment (and the assessment methodology) are both completely flawed, 100%.
so it would be best if i left it to you - and to others - to utilise the information and leads that i've given to make your *own* assessment.
as a reverse-engineer, i can foresee that the trainwreck *is* going to happen. i can't keep telling people that, though.
l.
On 02/16/2017 06:06 AM, Philip Hands wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Feb 16, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
if systemd is so bloated and all-encompassing that it in effect demands *all* privileges (it doesn't, but you know what i mean), it utterly defeats the object of having the security system in the first place.
This appears to be another instance of you conflating the init process with the project, but perhaps I'm misunderstanding you.
Are you claiming that systemd (the init) uses forks where sysvinit uses execs?
i don't know how you conclude i would say that when i don't mention sysvinit. why would there be an implication of sysvinit being involved when it's not mentioned?
Well, if you're saying that systemd is bad, it must be bad relative to something else since if the nearest likely alternative e.g. sysvinit does pretty-much the same thing then you're really saying very little.
The Daily Mail will cheerfully tell you that Coffee causes cancer, which is probably true, but only at about the same rate as pretty much everything else one could imagine consuming, so ... no news.
Coffee cures cancer? Sounds like you have been listening to todd talks too much.
sorry couldn't resist. ;)
i'm saying that SE/Linux's security model is based on the isolation of exec. but, that if the sheer overwhelming number of programs being exec'd is so huge, it becomes pretty pointless to even *have* such isolation.
Systemd execs a lot of things by dint of it being the system's init, does it not? This sounds almost like you're claiming that SElinux isn't capable of modeling any implementation of the init task.
That's why I was trying to tease out something about what makes this unique to sytemd from you. Hence the mention of sysvinit.
i provide this as a guide *without* spending the time to assess actual instances... because it's not my job to do so. and, also, with the sheer overwhelming number of *other* factors (all of them individually low-probability events), when combined using demster-shafer information theory, you don't *need* to go in-depth: to do so is completely pointless.
basically i'm saying, phil, knocking down one skittle by spending the time to track down one "hole" in what i say, is pointless. the entire design and deployment of systemd is like a dam made of swiss cheese.
there simply aren't enough fingers to plug all the hundreds of flaws... so there's little point in trying. this response (one of a long line of reasons why i will never *ever* use systemd) is just one response from a different angle, one that i have had at least one person publicly express gratitude for taking the time to explain, and one privately. who knows well enough and is old enough and ugly enough *not* to get involved in the cluster-fuck known as systemd.
I'm not trying to knock down skittles -- I'm trying to see whether what you're saying has any substance behind it, or is simply hand waving.
Cheers, Phil.
We should trust Luke okay? now can we all please drop this entire subject now? please?
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook@lists.phcomp.co.uk
-
John Luke Gibson -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
Philip Hands -
zap