Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Default Gentoo settings too weak in security?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Roman Zilka
n00b
n00b


Joined: 20 Apr 2013
Posts: 11
Location: Czech Republic

PostPosted: Sat May 18, 2013 4:35 pm    Post subject: Default Gentoo settings too weak in security? Reply with quote

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
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 9051

PostPosted: Sat May 18, 2013 4:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4218

PostPosted: Sat May 18, 2013 5:06 pm    Post subject: Reply with quote

See glep 58
It is a shame that there are no efforts to implement it :wink:
Back to top
View user's profile Send private message
Roman Zilka
n00b
n00b


Joined: 20 Apr 2013
Posts: 11
Location: Czech Republic

PostPosted: Sat May 18, 2013 5:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
Roman Zilka
n00b
n00b


Joined: 20 Apr 2013
Posts: 11
Location: Czech Republic

PostPosted: Sat May 18, 2013 5:20 pm    Post subject: Reply with quote

mv wrote:
See glep 58
It is a shame that there are no efforts to implement it :wink:

So there is one after all... Let's see what it's got.
Back to top
View user's profile Send private message
Roman Zilka
n00b
n00b


Joined: 20 Apr 2013
Posts: 11
Location: Czech Republic

PostPosted: Sat May 18, 2013 5:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
user
Tux's lil' helper
Tux's lil' helper


Joined: 08 Feb 2004
Posts: 132

PostPosted: Sun May 19, 2013 11:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
phajdan.jr
Developer
Developer


Joined: 23 Mar 2006
Posts: 1767
Location: Poland

PostPosted: Mon May 20, 2013 12:29 am    Post subject: Reply with quote

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. :wink:

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
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1566
Location: U.S.A.

PostPosted: Mon May 20, 2013 1:34 am    Post subject: Reply with quote

phajdan.jr wrote:
this can hopefully be dealt with... swiftly.

:lol:
_________________
pjp wrote:
I didn't misquote you, I just misunderstood you.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4218

PostPosted: Mon May 20, 2013 9:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2868
Location: Omnipresent

PostPosted: Mon May 20, 2013 10:00 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4218

PostPosted: Mon May 20, 2013 12:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
Roman Zilka
n00b
n00b


Joined: 20 Apr 2013
Posts: 11
Location: Czech Republic

PostPosted: Mon May 20, 2013 1:11 pm    Post subject: Reply with quote

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. :wink:

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
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Tue May 21, 2013 4:30 pm    Post subject: Reply with quote

I've always wondered why isn't https default from the get go.
Back to top
View user's profile Send private message
phajdan.jr
Developer
Developer


Joined: 23 Mar 2006
Posts: 1767
Location: Poland

PostPosted: Sun Jun 16, 2013 2:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1566
Location: U.S.A.

PostPosted: Sun Jun 16, 2013 3:08 am    Post subject: Reply with quote

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?
_________________
pjp wrote:
I didn't misquote you, I just misunderstood you.
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1241
Location: 42.68n 85.41w

PostPosted: Sun Jun 16, 2013 5:00 am    Post subject: Reply with quote

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.
_________________
cat /etc/*-release
Funtoo Linux - baselayout 2.2.0
consider this warning no. 1
https://wiki.gentoo.org/index.php?title=Special:Contributions/666threesixes666&offset=&limit=500&target=666threesixes666
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9013
Location: beyond the rim

PostPosted: Tue Jun 18, 2013 2:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum