View previous topic :: View next topic |
Author |
Message |
Roman Zilka n00b
Joined: 20 Apr 2013 Posts: 11 Location: Czech Republic
|
Posted: Sat May 18, 2013 4:35 pm Post subject: Default Gentoo settings too weak in security? |
|
|
I've been thinking about the trustworthiness of everything that I download from the Internet, install and run. The thing that got me started was the realization that by default:
* 'emerge --sync' and 'webrsync' use no authentication, i.e., I'm downloading something from somewhere;
* Manifests are signed, but the signature is not verified by emerge, i.e., the distfile/ebuild checksums in them can be arbitrary; I'm installing something from somewhere.
The chances of anything bad happening are tiny, but not zero. Yes, one can set their system up to make GPG verifications and stuff. What I'm thinking about is that these measures might as well be a part of the default Gentoo setup. Please add your comments on the topic before I try to open an official bug.
I propose these specific changes:
[1] Under *.gentoo.org, access to the mirrorlist, the handbook and all downloads limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for the aforementioned locations.
[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. Of course, the user can still skip this.
[3] Stage3 should come pre-configured for GPG-enabled webrsync by default and the handbook should recommend sticking to this route. The added difficulty is basically zero for those who'd already downloaded the public key in the earlier installation phases, and minimal for others (copying a few commands from the handbook).
[4] (alternative for [3]) Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21631
|
Posted: Sat May 18, 2013 4:55 pm Post subject: |
|
|
Files can be published over http, if you have a secure way of validating the file once it is received. For example, fetching the digest over https from a trusted host and validating the digest provides integrity for the received file.
GPG-enabled webrsync is a good security measure, but comes at a cost. The entire tree is fetched every time and snapshots are created only once a day. Therefore, users who want the absolute latest cannot use this. Also, users on restrictive bandwidth plans may find the repeated full download expensive compared to their daily/weekly rsync. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat May 18, 2013 5:06 pm Post subject: |
|
|
See glep 58
It is a shame that there are no efforts to implement it |
|
Back to top |
|
|
Roman Zilka n00b
Joined: 20 Apr 2013 Posts: 11 Location: Czech Republic
|
Posted: Sat May 18, 2013 5:15 pm Post subject: |
|
|
OK, reformulating items 1 and 3.
[1] Under *.gentoo.org, access to the mirrorlist and the handbook limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for these two locations.
[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. Of course, the user can still skip this.
[3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
[4] (alternative for [3]) Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. |
|
Back to top |
|
|
Roman Zilka n00b
Joined: 20 Apr 2013 Posts: 11 Location: Czech Republic
|
Posted: Sat May 18, 2013 5:20 pm Post subject: |
|
|
mv wrote: | See glep 58
It is a shame that there are no efforts to implement it |
So there is one after all... Let's see what it's got. |
|
Back to top |
|
|
Roman Zilka n00b
Joined: 20 Apr 2013 Posts: 11 Location: Czech Republic
|
Posted: Sat May 18, 2013 5:33 pm Post subject: |
|
|
OK, the GLEP covers item [4]. The rest is on the table.
[1] Under *.gentoo.org, access to the mirrorlist and the handbook limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for these two locations.
[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded.
[3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
[4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. |
|
Back to top |
|
|
user Apprentice
Joined: 08 Feb 2004 Posts: 202
|
Posted: Sun May 19, 2013 11:49 pm Post subject: |
|
|
I using webrsync with GPG check,
but a deep packet inspection should *not* disclose that I use a mirror host service for gentoo fun.
Using an "unsuspicious" mirror host via HTTPS connection can deal with it.
Lets check which mirror host supports out-of-the-box HTTPS connection:
Code: | # wget -qO - http://www.gentoo.org/main/en/mirrors3.xml | sed -n 's|.*http://\(.*\)<.*|https://\1|p' | sort -u | xargs wget -nv -O /dev/null -t 1 -T 1 2>&1 | grep URL:https
URL:https://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/ [1037/1037] -> "/dev/null" [1]
URL:https://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ [1006/1006] -> "/dev/null" [1]
URL:https://gentoo.mirror.pw.edu.pl/ [110/110] -> "/dev/null" [1] |
Only three mirror hosts supports HTTPS protocol.
One of them is disqualified, because we would leak gentoo usage via DNS query.
Only two, less choice currently. |
|
Back to top |
|
|
phajdan.jr Retired Dev
Joined: 23 Mar 2006 Posts: 1777 Location: Poland
|
Posted: Mon May 20, 2013 12:29 am Post subject: |
|
|
Roman Zilka wrote: | [2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. |
Feel free to file a bug for handbook changes. With Sven (swift) being around, this can hopefully be dealt with... swiftly.
Roman Zilka wrote: | [3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
[4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. |
I think the hope is that portage's migration to git will introduce GPG-signed commits. _________________ http://phajdan-jr.blogspot.com/ |
|
Back to top |
|
|
Bones McCracker Veteran
Joined: 14 Mar 2006 Posts: 1611 Location: U.S.A.
|
Posted: Mon May 20, 2013 1:34 am Post subject: |
|
|
phajdan.jr wrote: | this can hopefully be dealt with... swiftly. |
_________________
patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon May 20, 2013 9:33 am Post subject: |
|
|
phajdan.jr wrote: | I think the hope is that portage's migration to git will introduce GPG-signed commits. |
But AFAIK this should not involve users (in contrast to developers) who have no need for the full git history: For them rsync should still be the preferred option.
In fact, I would not want to store hundreds of MB of unnecessary history on all gentoo systems when I can keep the currrent portage tree in a 60MB squash filesystem. Unfortunately, in contrast to other VCS like bzr, git is very poor when it comes for thin/partial checkouts of data or history: AFAIK either it requires lot of storage or lot of transferred data. But on the other hand, I would want to get some kind of "signing" of the tree anyway... |
|
Back to top |
|
|
Hypnos Advocate
Joined: 18 Jul 2002 Posts: 2889 Location: Omnipresent
|
Posted: Mon May 20, 2013 10:00 am Post subject: |
|
|
A shallow git clone would have the same ease-of-use as rsync, as long the master repo is never rewound. _________________ Personal overlay | Simple backup scheme |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon May 20, 2013 12:21 pm Post subject: |
|
|
Hypnos wrote: | A shallow git clone would have the same ease-of-use as rsync, as long the master repo is never rewound. |
It would really only transfer the modified data by an accretive algorithm? I would expect it has to transfer all data if practically nothing is stored in .git, but I may be wrong. |
|
Back to top |
|
|
Roman Zilka n00b
Joined: 20 Apr 2013 Posts: 11 Location: Czech Republic
|
Posted: Mon May 20, 2013 1:11 pm Post subject: |
|
|
phajdan.jr wrote: | Roman Zilka wrote: | [2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. |
Feel free to file a bug for handbook changes. With Sven (swift) being around, this can hopefully be dealt with... swiftly. |
I filed this as #470750.
phajdan.jr wrote: | Roman Zilka wrote: | [3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
[4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. |
I think the hope is that portage's migration to git will introduce GPG-signed commits. |
How far away is the transition? Can that be told? |
|
Back to top |
|
|
_______0 Guru
Joined: 15 Oct 2012 Posts: 521
|
Posted: Tue May 21, 2013 4:30 pm Post subject: |
|
|
I've always wondered why isn't https default from the get go. |
|
Back to top |
|
|
phajdan.jr Retired Dev
Joined: 23 Mar 2006 Posts: 1777 Location: Poland
|
Posted: Sun Jun 16, 2013 2:57 am Post subject: |
|
|
Roman Zilka wrote: | How far away is the transition? Can that be told? |
Not sure if this is adding much: there is progress, but sort of slow. Also, I have an impression that as things are progressing, a bit more issues come up that add to the TODO list before transition can be fully made.
_______0 wrote: | I've always wondered why isn't https default from the get go. |
Good question, and I think it's totally reasonable. Feel free to file a bug (there might already be one). _________________ http://phajdan-jr.blogspot.com/ |
|
Back to top |
|
|
Bones McCracker Veteran
Joined: 14 Mar 2006 Posts: 1611 Location: U.S.A.
|
Posted: Sun Jun 16, 2013 3:08 am Post subject: |
|
|
Why isn't the gentoo CA certificate (the one used to sign the bugzilla cert, for example) distributed as part of our ssl ca cert package? _________________
patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
Back to top |
|
|
666threesixes666 Veteran
Joined: 31 May 2011 Posts: 1248 Location: 42.68n 85.41w
|
Posted: Sun Jun 16, 2013 5:00 am Post subject: |
|
|
i was thinking about this myself, from a completely different angle. like an rsync that verifies data of other rsync mirrors, white lists the mirror, and hands off to locked down trusted local mirror. like remote mirror has a checksum that must match the master servers checksum in case of mirror corruption, accidental or intentional. i was also thinking about a "locking" file system that would trigger updates of checksums. im just dreaming though, i have no skills to implement any of that, or knowledge if any of its already been done. i prefer the webrsync, its easier. im talking about like a wan clustering protocol, like drbd that when i hit gentoo.org it doesnt go to some server in alaska, but redirects me to the local mirror of the website in chicago. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9527 Location: beyond the rim
|
Posted: Tue Jun 18, 2013 2:52 pm Post subject: |
|
|
TBH, the truth is that the design of the ebuild system is pretty bad to secure properly. This is due to the large number of different inter-dependent components, the direct exposure of users to changes and the lack of real containers. Add on top of that the lack of a strong government body in Gentoo, the rather anarchic development model (everybody can touch almost everything) and the poor GPG interfaces in the past and you may see why this topic has been stalled for years (not accounting "idealistic" debates over WoT vs. central signing authority or different attack vector scenarios).
Note I'm not saying the above issues are bad in general, just that they are counter-productive for a secure distribution system. |
|
Back to top |
|
|
|