Re: Patch for chroot() in 2.5STABLE1

Henrik,

No, You're not biased, You're dead right. I have no sensitive
configuration data or SSL certificates in my chroot() jail on any of my
caches, so i never thought about the problem. Your idea of where to
apply chroot() is also good, though it leaves the confusion issue unless
done well and with plenty of easily available documentation.

Theoretical question: If an attack managed to crack Squid, wouldn't
configuration data and SSL certificates be available to him/her anyway?
After all, those data have to either be stored in memory or Squid has to
keep a file descriptor to them, right? Well, i guess i'm just thinking
in terms of a buffer overflow. Other attacks that may be able to reach
the filesystem may not be able to reach Squid's internals. Hm.

Could we work on a solution together? I would be happy to code it once
we have the ideas worked out. The problem is one that i find interesting
and that is important to me.

                        -&

P.S. Hope i didn't step on Your toes.

Henrik Nordstrom wrote:
> Both approaches have their merits.
>
> Being the author of the chroot_dir directive I may be slightly biased,
> but what I'd really like to see for Squid is that chroot_dir is applied
> after parsing the configuration file and referenced configuration data
> (including SSL certificates for https_port) and writing of pid file, but
> before checking paths to helpers etc..
>
> For security reasons I do not want to have configuration data within the
> chroot jail, and on a SSL enabled Squid SSL certificates and keys
> certainly should not need to be within the chroot jail.
>
> Regards
> Henrik
>
>
>
> Andrew Rucker Jones wrote:
>
>>Hi everybody!
>>Don't know if i managed to get subscribed to the list, but i'll try
>>posting. :)
>
>
> You managed.. even if you did not exacly follow the protocol, but close
> enoght.
>
>
>>Primary disadvantage of the old chroot() method: The configuration file
>>was parsed before doing a chroot(), so many files and directories had to
>>be mirrored both inside of the chroot() jail and outside. It is also
>
> [...]
>
>>Disadvantages of the new method (which uses a command line switch and
>>immediately performs the chroot):
>
> [...]
>
> and less secure as all configuration data needs to be available within
> the jail.
>
>
>>Besides that, i fixed the spelling and grammar errors i ran across, and
>>i took out the part in the man page about reading the FAQ that comes
>>with the distribution, because the FAQ doesn't seem to come with the
>>distribution anymore (or i'm blind).
>
>
> I'll ltry to ook into these in the weekend, unless someone else beats me
> to it.
>
> the FAQ has never been part of the distribution (perhaps should, but
> that is another question).
>
>
>>Two small points about the Squid Web pages:
>>http://www.squid-cache.org/Devel/ includes a reference to
>>squid-dev-request@squid-cache.org, but it needs to be
>>squid-dev-subscribe@squid-cache.org.
>
>
> Should have a reference to mailing-lists.html me thinks..
>
>
>>http://www.squid-cache.org/Devel/guidelines.html claims that indent
>>should be run with the options -npsl AND -psl. Somehow i doubt it,
>>unless i'm misreading the indent man page.
>
>
> Well.. it is the options we use.. but this is only of concern to the
> core developers. Other developers only need to make sure they roughtly
> follow the style of the existing code and produces clean patches with
> only their changes.. running indent is "dangerous" as it may easily end
> up reformatting other code making it almost impossible to diff the
> changes.
>
>
>>Finally, is there still interest in finding an SNMP maintainer? I would
>>be interested in being that person, but i make no promises yet. Just
>>seeing if there's still a need.
>
>
> Sure. It is an area not being actively looked after, only patched up as
> needed. There is several errors and shortcomings in the SNMP
> implementation, and I am sure there is many interesting values that
> cannot be read via SNMP at the moment..
>
> There is also a great need to integrate with system SNMP agents where
> possible. Many NMS systems have trouble monitoring odd SNMP ports.
>
> Regards
> Henrik

-- 
GPG key / Schlüssel -- http://simultan.dyndns.org/~arjones/gpgkey.txt
Encrypt everything. / Alles verschlüsseln.