[Arm-netbook] A suggestion why Systemd may be bad

[John Luke Gibson]

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Sen

[m***@gmail.com]

Post by John Luke Gibson
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

Post by John Luke Gibson
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.

Post by John Luke Gibson
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.

Post by John Luke Gibson
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Philip Hands]

Post by John Luke Gibson
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.

[John Luke Gibson]

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

Post by Philip Hands

Post by John Luke Gibson
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 [[phone]] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large

[Luke Kenneth Casson Leighton]

Post by John Luke Gibson
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp

[zap]

Post by Luke Kenneth Casson Leighton

Post by John Luke Gibson
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
* 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.

Post by Luke Kenneth Casson Leighton
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u

[Luke Kenneth Casson Leighton]

Post by zap
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.

Post by zap
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.

Post by zap
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne

[Philip Hands]

Post by Luke Kenneth Casson Leighton
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.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file

[Philip Hands]

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
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.

[Luke Kenneth Casson Leighton]

Post by Philip Hands
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.

[zap]

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
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. ;)

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
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?

Post by Philip Hands
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[John Luke Gibson]

Sorry, I just read your reply Mike. I think that answers any curiosity I had.
I appreciate it very much.

This is makes sense as I imagine it to be part of the problem GNU/Mach
is trying to solve (separating components of the system better, and
with more micro-managed permissions?).

Anyway, above and beyond explaining, both Mike and Philip.. Thx!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Sen