On 2012-01-15 at 20:23 +0700, Ivan Shmakov wrote:
> The documentation reads:
>
> --cut: http://exim.org/exim-html-current/doc/html/spec_html/ch39.html --
> To replace the parameters with new ones, instead of deleting the
> file and letting Exim re-create it, you can generate new parameters
> using certtool and, when this has been done, replace Exim’s cache
> file by renaming. The relevant commands are something like this:
>
> # rm -f new-params
> # touch new-params
> # chown exim:exim new-params
> # chmod 0400 new-params
> # certtool --generate-privkey --bits 512 >new-params
> # echo "" >>new-params
> # certtool --generate-dh-params --bits 1024 >> new-params
> # mv new-params gnutls-params
> --cut: http://exim.org/exim-html-current/doc/html/spec_html/ch39.html --
>
> Arguably, it doesn't make sense to use >> here. Also, while it
Yes it does. The first invocation of certtool will truncate, the echo
and second invocation append. The logic is correct.
> may not be a problem in practice, the use of touch(1) followed
> by chmod(1) is a race, easily avoidable with the use of the
> umask command.
Is the threat model an untrusted local user gaining access to the
entropy, by getting an open file descriptor after the file creation and
before the chmod and then using the fd to read the entropy data out?
And then use this to predict session keys and sniff traffic they might
not otherwise have access to?
If there are such untrusted local users, then why was Exim built with
more a more open value of SPOOL_DIRECTORY_MODE than the default? It
should be 0750, so only root and the Exim run-time user have access to
the spool directory. So only root and the file owner can access it to
open it, unless someone has deliberately weakened the security of the
default configuration.
> Consider, e. g., the following example code instead:
>
> #!/bin/sh
> rm -f new-params
> umask 0277
> {
> certtool --generate-privkey --bits 512
> echo ""
> certtool --generate-dh-params --bits 1024
> } > new-params
> chown exim:exim new-params
> mv new-params gnutls-params
Looks good, although my recollection is that in some older shell on some
systems (which Exim runs on), braces for command-pipelines don't
redirect well and you'd need to use parentheses and a sub-shell.
> Should something like mktemp(1) be used as well, the rm(1)
> vs. touch(1) race will also be avoided, and it will be perfectly
> safe to run multiple instances of the code above at once. (Just
> as with Exim computing new D-H parameters by itself.)
The rm vs touch race is non-existent, because this is not happening in
/tmp, but in the Exim spool directory which is only writeable by the
Exim run-time user (and root). The target file is replaced atomically.
Any process which can interfere with the file creation can already do
anything at all that the Exim processes can do.
The hoops to be jumped through for /tmp and its like are not needed in
this case.
I'm unconvinced that anything here needs to change.
--
https://twitter.com/syscomet
