Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #6084 > unrolled thread

Re: Concerns about Security of packages in Debain OS and the Operating system itself.

Back to article view | Back to linux.debian.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Concerns about Security of packages in Debain OS and the Operating system itself. lkcl <luke.leighton@gmail.com> - 2022-04-17 21:50 +0200
    Re: Concerns about Security of packages in Debain OS and the  Operating system itself. Stephan Verbücheln <verbuecheln@posteo.de> - 2022-04-18 19:50 +0200
    Re: Concerns about Security of packages in Debain OS and the  Operating system itself. Adam McKenna <adam@flounder.net> - 2022-05-23 19:30 +0200
      Re: Concerns about Security of packages in Debain OS and the  Operating system itself. lkcl <luke.leighton@gmail.com> - 2022-05-23 20:40 +0200
        Re: Concerns about Security of packages in Debain OS and the  Operating system itself. Adam McKenna <adam@flounder.net> - 2022-05-23 21:10 +0200
          Re: Concerns about Security of packages in Debain OS and the  Operating system itself. Adam McKenna <adam@flounder.net> - 2022-05-23 21:20 +0200
          Re: Concerns about Security of packages in Debain OS and the  Operating system itself. lkcl <luke.leighton@gmail.com> - 2022-05-23 21:30 +0200
          Re: Concerns about Security of packages in Debain OS and the  Operating system itself. Paul Wise <pabs@debian.org> - 2022-05-25 03:20 +0200
            Re: Concerns about Security of packages in Debain OS and the  Operating system itself. piorunz <piorunz@gmx.com> - 2022-05-25 14:10 +0200

#6084 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

On 17/04/2022 19:26, Satvik Sinha wrote:

> abusing your OS's reputation?

i believe the answer is in the question. debian is based on distributed trust.  i did the analysis (took 3 weeks): it is literally the only distro in the world with an inviolate chain of trust from a large keyring dating back 20 years that is itself GPG-signed as a package, with a package distribution chain from source where all components within the chain up to release are unbroken and inviolate.

take ubuntu for example: whilst it has the exact same technology the size of the developer pool, comprising the web of trust, is both much smaller and also controlled by one Corporation: Canonical. Canonical says "jump", the developers ask "how high".

take Suse, Fedora etc: their RPM packages break the chain of trust by failing to properly include a GPG Signature of the Release (i do not recall the exact details, i did the analysis 4 years ago)

take Archlinux: their community is vulnerable to unverified github repositories being abandoned, a hacker re-registering them, and a trojan uploaded and distributed automatically.

i won't even bother going into the absolute moronic practice of "trusting" HTTPS: node, pypi, etc should be blindingly obviously untrustworthy, with the website being a prime hacking target if nothing else.

even GNU packages are hopelessly inadequately secure as far as social engineering and hacking are concerned.

debian is not a single centralised repository, it is controlled by no-one. you have to compromise hundreds of independent developers before you make any headway, and as a result it was trusted by e.g. the Venezuelan Government as the basis for their own distro, many years ago.

there is not even a centralised dependency on a website: packages may be securely distributed by Carrier Pigeon or printed out on paper and OCR scanned if you really want to because there is a full GPG Chain and Checksums, right back to the source code.

and that (GPG Chains) basically, is the key.  anyone stupid enough to do something stupid is going to be throwing away their reputation, not just within the debian project as a maintainer, but for life.

you abuse your position as a maintainer by putting in trojan code, because that trojan package had to be GPG Signed, you have to make a *public and irreversible declaration* which will remain in historical archives for the rest of your life and beyond.

this would result in catastrophic consequences for not just their involvement in debian (which would be terminated with prejudice), but because their GPG Signature on the trojan package is public, inviolate and irrevocable, it would also have catastrophic consequences for their career in IT because nobody would ever trust them in a position of responsibility, ever again. they'd be flipping burgers for the rest of their life.

fundamentally, then, you are assuming that there is "one controller of debian", which is false.  there are literally hundreds of *independent* developers, all of whom know their responsibility, all of whom know that they have all other independent developers keeping an eye on them.

this makes debian pretty much the only distro that could be trusted to remain true to humanity and to its principles and its charter. even when some of them (you know who you are) are when it comes down to it not very nice people, they can at least be trusted to do the right thing.

l.

[toc] | [next] | [standalone]

#6086 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

> i did the analysis (took 3 weeks)

Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.

Also I like to add that reproducible builds are an excellent addition
to the mechanisms you are describing.

Regards 

[toc] | [prev] | [next] | [standalone]

#6138 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Multipart message — attachments visible in raw view] — view raw

> i believe the answer is in the question. debian is based on distributed
trust.  i did the analysis (took 3 weeks): it is literally the only distro
in the world with an inviolate chain of trust from a large keyring dating
back 20 years that is itself GPG-signed as a package, with a package
distribution chain from source where all components within the chain up to
release are unbroken and inviolate.

This is not an answer to the question though, OP was asking how we prevent
abuse of that trust.

On Sun, Apr 17, 2022 at 12:42 PM lkcl <luke.leighton@gmail.com> wrote:

>
>
> On 17/04/2022 19:26, Satvik Sinha wrote:
>
> > abusing your OS's reputation?
>
> i believe the answer is in the question. debian is based on distributed
> trust.  i did the analysis (took 3 weeks): it is literally the only distro
> in the world with an inviolate chain of trust from a large keyring dating
> back 20 years that is itself GPG-signed as a package, with a package
> distribution chain from source where all components within the chain up to
> release are unbroken and inviolate.
>
> take ubuntu for example: whilst it has the exact same technology the size
> of the developer pool, comprising the web of trust, is both much smaller
> and also controlled by one Corporation: Canonical. Canonical says "jump",
> the developers ask "how high".
>
> take Suse, Fedora etc: their RPM packages break the chain of trust by
> failing to properly include a GPG Signature of the Release (i do not recall
> the exact details, i did the analysis 4 years ago)
>
> take Archlinux: their community is vulnerable to unverified github
> repositories being abandoned, a hacker re-registering them, and a trojan
> uploaded and distributed automatically.
>
> i won't even bother going into the absolute moronic practice of "trusting"
> HTTPS: node, pypi, etc should be blindingly obviously untrustworthy, with
> the website being a prime hacking target if nothing else.
>
> even GNU packages are hopelessly inadequately secure as far as social
> engineering and hacking are concerned.
>
> debian is not a single centralised repository, it is controlled by no-one.
> you have to compromise hundreds of independent developers before you make
> any headway, and as a result it was trusted by e.g. the Venezuelan
> Government as the basis for their own distro, many years ago.
>
> there is not even a centralised dependency on a website: packages may be
> securely distributed by Carrier Pigeon or printed out on paper and OCR
> scanned if you really want to because there is a full GPG Chain and
> Checksums, right back to the source code.
>
> and that (GPG Chains) basically, is the key.  anyone stupid enough to do
> something stupid is going to be throwing away their reputation, not just
> within the debian project as a maintainer, but for life.
>
> you abuse your position as a maintainer by putting in trojan code, because
> that trojan package had to be GPG Signed, you have to make a *public and
> irreversible declaration* which will remain in historical archives for the
> rest of your life and beyond.
>
> this would result in catastrophic consequences for not just their
> involvement in debian (which would be terminated with prejudice), but
> because their GPG Signature on the trojan package is public, inviolate and
> irrevocable, it would also have catastrophic consequences for their career
> in IT because nobody would ever trust them in a position of responsibility,
> ever again. they'd be flipping burgers for the rest of their life.
>
> fundamentally, then, you are assuming that there is "one controller of
> debian", which is false.  there are literally hundreds of *independent*
> developers, all of whom know their responsibility, all of whom know that
> they have all other independent developers keeping an eye on them.
>
> this makes debian pretty much the only distro that could be trusted to
> remain true to humanity and to its principles and its charter. even when
> some of them (you know who you are) are when it comes down to it not very
> nice people, they can at least be trusted to do the right thing.
>
> l.
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#6139 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

On Mon, May 23, 2022 at 6:28 PM Adam McKenna <adam@flounder.net> wrote:
>
> > i believe the answer is in the question. debian is based on distributed trust.  i did the analysis (took 3 weeks): it is literally the only distro in the world with an inviolate chain of trust from a large keyring dating back 20 years that is itself GPG-signed as a package, with a package distribution chain from source where all components within the chain up to release are unbroken and inviolate.
>
> This is not an answer to the question though, OP was asking how we prevent abuse of that trust.

reputation, and potentially criminal and civil proceedings.

all identities are known, and inviolate-known [through the
above-described chain].
anyone stupid enough to abuse their position may only do so once, at which
point their GPG key is revoked.

given that GPG key-signing parties require people's real-world identities
to be known, it is easy to track down who signed whose key (it's right
there in the keyring-archive], and request that the signer provide assistance
to the relevant authorities in proving that real-world identity.

this will sufficiently piss off those people that trusted them that they will
be unlikely to work with them ever again [reputation]

in addition there is the Debian Trademark which if brought into disrepute
through abuse could be utilised to seek damages against the perpetrator.

bottom line is that it would be a spectacularly stupid thing to do to violate
the trust and responsibility of being a Debian Maintainer, and the really
interesting bit to me is that this all works in an entirely distributed manner
and can all entirely be done entirely without a single centralised authority,
i.e. *not* having to trust f*****g google or f*****g github with anyone's
real-world identity in any way shape or form.

l.

[toc] | [prev] | [next] | [standalone]

#6140 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Multipart message — attachments visible in raw view] — view raw

> anyone stupid enough to abuse their position may only do so once, at
which point their GPG key is revoked.

You are talking about a deterrent though.  I think the question is, what if
someone cares more about their political cause than retaining their
uploader access?

What if someone's keys are compromised and an attacker uploads a
compromised package?

Do we have ways of detecting these breaches or do we rely solely on user
reports?

On Mon, May 23, 2022 at 11:22 AM lkcl <luke.leighton@gmail.com> wrote:

> On Mon, May 23, 2022 at 6:28 PM Adam McKenna <adam@flounder.net> wrote:
> >
> > > i believe the answer is in the question. debian is based on
> distributed trust.  i did the analysis (took 3 weeks): it is literally the
> only distro in the world with an inviolate chain of trust from a large
> keyring dating back 20 years that is itself GPG-signed as a package, with a
> package distribution chain from source where all components within the
> chain up to release are unbroken and inviolate.
> >
> > This is not an answer to the question though, OP was asking how we
> prevent abuse of that trust.
>
> reputation, and potentially criminal and civil proceedings.
>
> all identities are known, and inviolate-known [through the
> above-described chain].
> anyone stupid enough to abuse their position may only do so once, at which
> point their GPG key is revoked.
>
> given that GPG key-signing parties require people's real-world identities
> to be known, it is easy to track down who signed whose key (it's right
> there in the keyring-archive], and request that the signer provide
> assistance
> to the relevant authorities in proving that real-world identity.
>
> this will sufficiently piss off those people that trusted them that they
> will
> be unlikely to work with them ever again [reputation]
>
> in addition there is the Debian Trademark which if brought into disrepute
> through abuse could be utilised to seek damages against the perpetrator.
>
> bottom line is that it would be a spectacularly stupid thing to do to
> violate
> the trust and responsibility of being a Debian Maintainer, and the really
> interesting bit to me is that this all works in an entirely distributed
> manner
> and can all entirely be done entirely without a single centralised
> authority,
> i.e. *not* having to trust f*****g google or f*****g github with anyone's
> real-world identity in any way shape or form.
>
> l.
>

[toc] | [prev] | [next] | [standalone]

#6141 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Multipart message — attachments visible in raw view] — view raw

> they get one and only one chance to do something that stupid.

So the answer is that we have no way of preventing a developer from
intentionally sabotaging a package in any / as many ways as they choose and
the only risk to them is losing their uploader access after the fact?

>the response is swift: there was a debian developer wrongfully arrested
for running a TOR exit node. their key was revoked immediately.

How was this incident detected?


On Mon, May 23, 2022 at 12:07 PM lkcl <luke.leighton@gmail.com> wrote:

> On Mon, May 23, 2022 at 7:59 PM Adam McKenna <adam@flounder.net> wrote:
> > You are talking about a deterrent though.  I think the question is,
> > what if someone cares more about their political cause than
> > retaining their uploader access?
>
> they get one and only one chance to do something that stupid.
>
> > What if someone's keys are compromised
>
> the response is swift: there was a debian developer wrongfully
> arrested for running a TOR exit node. their key was revoked
> immediately.
>
> l.
>

[toc] | [prev] | [next] | [standalone]

#6142 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

On Mon, May 23, 2022 at 7:59 PM Adam McKenna <adam@flounder.net> wrote:
> You are talking about a deterrent though.  I think the question is,
> what if someone cares more about their political cause than
> retaining their uploader access?

they get one and only one chance to do something that stupid.

> What if someone's keys are compromised

the response is swift: there was a debian developer wrongfully
arrested for running a TOR exit node. their key was revoked
immediately.

l.

[toc] | [prev] | [next] | [standalone]

#6143 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2022-05-24 at 16:27 +0100, piorunz wrote:

> Important note: Disabling bullseye-updates is actually causing
> point-release updates to be delivered on one, predetermined date,
> bundled all together. By disabling this entry you still get them all,
> but in controlled fashion, you are not "beta tester" of these packages.

This is not exactly correct. The bullseye-updates suite should be used
by almost all users. The only suite where you are really a beta tester
for the next point release is bullseye-proposed-updates. The other two
suites recieve only very important updates:

bullseye: read-only except during point releases

bullseye-security: receives security updates regularly

bullseye-updates: receives occasional time-sensitive and important
updates, such as updates to the timezone database, which often happen
just days before the timezone changes, or fixes for packages that get
completely broken by some external services on the Internet, or fixes
for packages that were initially broken but that wasn't found. There
are only three updates in it currently, two of them are updates to the
timezone database and one is clamav, which sometimes needs updates so
it can continue to pull in antivirus detections.

https://deb.debian.org/debian/dists/bullseye-updates/main/source/Sources.xz

bullseye-proposed-updates: the contents of the next point release;
some changes come from bullseye-security, some from bullseye-updates
and some from package maintainers.

https://release.debian.org/proposed-updates/stable.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#6144 — Re: Concerns about Security of packages in Debain OS and the Operating system itself.

Hi Paul,

On 25/05/2022 02:10, Paul Wise wrote:

> bullseye-updates: receives occasional time-sensitive and important
> updates, such as updates to the timezone database, which often happen
> just days before the timezone changes, or fixes for packages that get
> completely broken by some external services on the Internet, or fixes
> for packages that were initially broken but that wasn't found.

All what you described here is not important for OP who wants to reduce
his attack surface from malicious developer attack scenario.
And I argue, not important for typical security conscious home user either.

> There
> are only three updates in it currently, two of them are updates to the
> timezone database and one is clamav, which sometimes needs updates so
> it can continue to pull in antivirus detections.

All of them will land in "bullseye" repository on point release. Correct?

My system will learn timezone changes in (for example) Barbados,
Seychelles or elsewhere when time comes for point release. I don't need
it now, I don't live there.
Same goes when user does not use ClamAV: No need for antivirus definitions.
And when very rare occasion will occur that software in Stable will
suddenly broke due to server side updates of some software, user can
always stop, think and investigate. No need to keep bullseye-updates
enabled 24/7/365 and never use it (if we exclude timezone updates,
antivirus definitions, there is nothing really urging users to enable
this repository). This would be widening exposure surface without any
real benefit.
Situation like this happened recently, Telegram has cut-off old client
versions on server side, Telegram bullseye stopped working. Soon after
maintainer dropped new Telegram to bullseye-backports, so people could
upgrade in controlled fashion. Please notice that having
bullseye-updates would not help in this example.

>
> https://deb.debian.org/debian/dists/bullseye-updates/main/source/Sources.xz
>
> bullseye-proposed-updates: the contents of the next point release;
> some changes come from bullseye-security, some from bullseye-updates
> and some from package maintainers.

That's Stable's "beta testing" for sure. I didn't mentioned that to the
OP, I don't use it myself.
>
> https://release.debian.org/proposed-updates/stable.html
>


--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web