Secure kernel updating

[Alt]

Ports sources are checked with distinfo files
portsnap - has ability verify signature
freebsd-update - have it too

How securing is done for kernel sources? Afaik cvsup cannot check this; svn.freebsd.org not works over https... Is there some way to ensure freebsd mirror is used?

[mk]

this is discussed on the mail lists. if i find it i will post later.

EDIT: i'm unable to find it. i kinda dislike search engine for mailing lists now.
iirc don't be bothered by the lack of integrity of kernel sources. reason is the effort to setup cvsup machine+it have to be mim which elevate the probability to get caught. further you are not sure when the target will update, if update at all - homegrown kernel patches etc. i cant remember whether it was in security@ or questions@. anyway if you have high valuable machine, then took some more in depth care.

[fender0107401]

I got this from csup(1):


-s Suppresses the check of each client file’s status against
what is recorded in the list file. Instead, the list file is
assumed to be accurate. This option greatly reduces the
amount of disk activity and results in faster updates with
less load on the client host. However it should only be used
if client’s files are never modified locally in any way.
Mirror sites may find this option beneficial to reduce the
disk load on their systems. For safety, even mirror sites
should run csup occasionally (perhaps once a day) without the
-s option.

Without the -s option, csup performs a stat(2) call on each
file and verifies that its attributes match those recorded in
the list file. This ensures that any file changes made out‐
side of csup are detected and corrected.

If the -s option is used when one or more files have been
modified locally, the results are undefined. Local file dam‐
age may remain uncorrected, updates may be missed, or csup
may abort prematurely.

Maybe that can answer your question.

However, I don't know how csup(1) ensure the "list file" is correct?

[Alt]

Seems this key use just to update, discarding local changes(for merge). Its not really thing im interesting

[anomie]

This is a legitimate question. FreeBSD is installed on many critical infrastructure hosts. If there are no digital signatures (or even crytpo hashes) for kernel sources, it would be interesting to know the reasoning.

Please let us know the outcome if you end up pinging the mailing lists.

[fender0107401]

If a intruder do the following steps:

1. Intrude my dns server and give me a fake ip address when I run "make update" in "/usr/src".

2. Build a fake freebsd server and change some important system file.

I think the intruder can alter some files in this way, if the csup(1) do not have any cryptographic mechanism.

[Alt]

fender0107401, exactly. "Intruder" can poison/control some ISP's or other DNS. This can lead to kernel corruption, as a result - your server will be part of botnet (not so bad as it can be).
Maybe it can be solved via tools like mtree or somewhat like this, but without decisions from developers it may not be done well..

[mk]

Foiling MITM attacks on source and ports trees (http://docs.freebsd.org/mail/archive/2009/freebsd-questions/20090104.freebsd-questions.html)

well i find it. this is it. by the way - brute force ;) search archive by hand.

[anomie]

Thanks. It is a good discussion, but the points brought up by cpghost (AT) cordula are not thoroughly addressed there. It seems like this could be implemented using a FreeBSD sources pubkey pair, with digitally signed hashes for the sources. (Or even a source tarball, with a digitally signed hash for it. But that would completely change the way most of us currently update sources.)

[fender0107401]

Definitely that is a security hole. I always "make update" through csup(1). I really desire add some new features to csup(1) in order to ensure I can get the correct source tree exactly.

Can we adopt some asymmetric encryption protocol?
1. Give every server listed in handbook or official site a private-key, and release the corresponding public-key through a package regularly by a very respectable man, like the security team leader. Every one can identify this package easily though md5 or something else.
2. Install the package in the system, and let csup(1) know the package.

For every file, the server generate a signature. Then we have a signature tree. The client can identify every file through the corresponding public-key. If something wrong let csup(1) send a message to a server or a mailing list that always watched by many people (optional or can be configured by the system administrator).

Side effects:
1. The server need generate the signature tree for the source tree that will cause a lot of cost. That may be difficult for a busy server. :(
2. The client only need download the source tree and the signature tree then identify them. That should be relatively easy. :(