Your message dated Thu, 30 Jul 2015 17:19:14 -0300
with message-id <[email protected]>
and subject line Re: Bug#794120: ruby: please implement a way to forcibly
disable download/installation of (Debian external) gems
has caused the Debian Bug report #794120,
regarding ruby: please implement a way to forcibly disable
download/installation of (Debian external) gems
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
794120: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794120
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ruby
Version: 1:2.1.5.1
Severity: wishlist
Tags: security
Hi.
AFAIU, the gems integration into ruby allows one (e.g. in principle also
other packages) to download/install software which doesn't come vi the
Debian Archives (i.e. I'm not talking about properly packaged "gems", as
e.g. ruby-xmlparser).
Correct me if I'm wrong.... =)
There are several, especially security, problems with such external
downloading/injecting features - similar to those as one has them with
many (but not all) downloader packages.
- The put trust for code which gets executed (likely even as root) into
another party (the ruby gem author), for which the Debian user/admin
likely doesn't want to put trust in.
- It circumvents the package management system.
- And also the security support from Debian.
- If an attacker can control the code of the gem (which is downloaded
in such manner) he could selectively attack only certain people, making
such attack basically impossible to ever notice (which is less easy
when the same code is guaranteed to be used by *all*, as it's the case
when it's properly packaged).
- On a first glance (I haven't looked into all details) it seems that the
certs from ca-certificates would be used for authenticating such
external gems? Or did I get that wrong?
Anyway, that would really be a serious problem, that contains gazillions
of CAs where many of them have proven countless times to be either
incompetent or simply straight malicious.
It's of course fine to have probperly (Debian)packaged gems being used,
but any form of possible way that code get's installed (without the admin
or user doing it manually or via the package management system (talking
about dpkg/apt here)) is IMHO a quite severe security breach, and as such
there should be a way to have ruby gems in Debian configured (per default)
so that this isn't possible.
But just that seems to work:
e.g.
# gem install rubygems-update
Fetching: rubygems-update-2.4.8.gem (100%)
Successfully installed rubygems-update-2.4.8
1 gem installed
Installing ri documentation for rubygems-update-2.4.8...
Installing RDoc documentation for rubygems-update-2.4.8...
#
And that even though there seem to be no trusted certificate configured:
# gem cert --list
#
Best wishes,
Chris.
--- End Message ---
--- Begin Message ---
Control: tag -1 wontfix
On Thu, Jul 30, 2015 at 08:52:11PM +0200, Christoph Anton Mitterer wrote:
> Package: ruby
> Version: 1:2.1.5.1
> Severity: wishlist
> Tags: security
>
>
> Hi.
>
> AFAIU, the gems integration into ruby allows one (e.g. in principle also
> other packages) to download/install software which doesn't come vi the
> Debian Archives (i.e. I'm not talking about properly packaged "gems", as
> e.g. ruby-xmlparser).
>
> Correct me if I'm wrong.... =)
Yes, you are right. Ruby comes with its own package manager, as does
pretty much any other language these days.
If you don't trust software from outside of the Debian archive, don't
install it.
> There are several, especially security, problems with such external
> downloading/injecting features - similar to those as one has them with
> many (but not all) downloader packages.
>
> - The put trust for code which gets executed (likely even as root) into
> another party (the ruby gem author), for which the Debian user/admin
> likely doesn't want to put trust in.
> - It circumvents the package management system.
> - And also the security support from Debian.
> - If an attacker can control the code of the gem (which is downloaded
> in such manner) he could selectively attack only certain people, making
> such attack basically impossible to ever notice (which is less easy
> when the same code is guaranteed to be used by *all*, as it's the case
> when it's properly packaged).
That's all true, but unless you found a way for random stuff being
installed without an explicit user request, then there is nothing to be
fixed.
> - On a first glance (I haven't looked into all details) it seems that the
> certs from ca-certificates would be used for authenticating such
> external gems? Or did I get that wrong?
> Anyway, that would really be a serious problem, that contains gazillions
> of CAs where many of them have proven countless times to be either
> incompetent or simply straight malicious.
ca-certificates allows you to pick which CAs you want to trust. If you
don't trust any, or all of them, you can easily disable their root
certificates.
> It's of course fine to have probperly (Debian)packaged gems being used,
> but any form of possible way that code get's installed (without the admin
> or user doing it manually or via the package management system (talking
> about dpkg/apt here)) is IMHO a quite severe security breach, and as such
> there should be a way to have ruby gems in Debian configured (per default)
> so that this isn't possible.
Language-specific package managers are here to stay. If system
administrators decide to use them instead of apt to install stuff, they
are entitled to do it and take the consequences.
> But just that seems to work:
> e.g.
> # gem install rubygems-update
> Fetching: rubygems-update-2.4.8.gem (100%)
> Successfully installed rubygems-update-2.4.8
> 1 gem installed
> Installing ri documentation for rubygems-update-2.4.8...
> Installing RDoc documentation for rubygems-update-2.4.8...
> #
Yes, it works. You logged in as root, told the system to do something,
and it did.
> And that even though there seem to be no trusted certificate configured:
> # gem cert --list
Yes, we drop the list of builtin certificates from rubygems in favor of
ca-certificates, exactly to give the user control over who to trust.
--
Antonio Terceiro <[email protected]>
signature.asc
Description: Digital signature
--- End Message ---
