[Discuss] Debian 12 vs. WSL 1
Derek Martin
invalid at pizzashack.org
Tue Jun 20 16:39:59 EDT 2023
On Tue, Jun 20, 2023 at 03:48:22PM -0400, Rich Pieri wrote:
> On Tue, 20 Jun 2023 14:08:11 -0500
> Derek Martin <invalid at pizzashack.org> wrote:
>
> > Obviously I disagree, particularly when the customizations are
> > basically trivial, one-time work.
>
> That's the rub. You see it as a one-time thing. Whereas I see it as a
> one-time thing times the approximately 4000 machines and counting that
Unless for some reason (which may exist, but which I can't imagine)
that defies your automation capabilities, you have to manually
maintain those symlinks, or you have to manually add them, then it is
indeed one-time work. If you commented/documented the place where
that happens, its existence and reason will not be institutionally
forgotten, but on a day-to-day basis it well could be.
> I've deployed as part of my job, one that actively makes my job more
> complicated due to all these thousands of one-time things breaking
> in-place upgrades of various systems.
That's a different problem... again, one I never had, whether by
design or by luck (perhaps a bit of both). Customizations were
typically (relatively) few and "built-in" to our process. Size can
matter, but usually only should when the environment is chaos. If
that's your situation you have my sympathy.
I've managed networks with tens of thousands of machines, but they
were extremely homogenous. The most heterogeneous environment I
managed had at most a few hundred (not counting the irrelevant Windows
desktops), but to the best of my recollection we spent literally zero
time worrying about the management of machine/OS customizations once
they were added to our automation, which was immediately upon
discovering the need for them.
> > Demonstrate how you can subvert this as a non-root user (assume your
> > sysadmin/vendor/developer is not a moron), and we'll talk again. Just
> > because you found a vendor who got it wrong doesn't mean it's a
> > problem.
>
> I call straw-man.
A straw man would involve providing an example that does not
demonstrate the point I made, but a different one that is easier to
argue. My script exactly demonstrates the point I made: You can't
compromise a script (or other program) in the manner you described
when it takes care on its own behalf that its PATH is set up properly.
And I think, based on many years of your messages, you actually know
that. This is not a straw man.
The only way you could effect such a compromise is if some genuine
vulnerability existed: the paths were user-writable, the programs
themselves were user-writable, etc.. That's why I said to assume your
sysadmin was not a moron.
> immediately see an exploit in your code does not demonstrate that all
> of your code in all of your environments is immune to compromise.
I never claimed that... only that insodiong you can't exploit it due
to that specific mechanism, which is the only mechanism relevant to
this discussion.
> I also think I'm finished here.
Fair enough.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
More information about the Discuss
mailing list