Re: Securtiy_file_gen in a server format development
| Newsgroups | gmane.comp.web.squid.devel |
|---|---|
| Message-ID | <[email protected]> |
OK. So I would try to run a test of three squid 4.4 instances with a NFS share for /var/squid/ssl_db ontop of NFSv3 and NFSv4. If the network speed is fast then it's a nice thing to have on a busy cluster to reduce the load of encryption "part" of the CPU (if it's worth something). The use case of logging certificate generation and couple other related features is security "auditing". Like SELinux has audit log that can help to decide on specific actions, in a similar way some organizations. If security auditing is not enough to allow investigation of content leakage or some other scenario I cannot think about another option. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: [email protected] -----Original Message----- From: squid-dev <[email protected]> On Behalf Of Alex Rousskov Sent: Sunday, December 30, 2018 19:08 To: [email protected] Subject: Re: [squid-dev] Securtiy_file_gen in a server format development On 12/29/18 11:45 PM, Eliezer Croitoru wrote: > From what I understood until now it seems that the current ssl_db > directory structure is simple enough that it might be possible to share > it across a NFS store. I would expect NFS store to work in environments that support file locking over NFS. For example, NFS flock(2) does not work with Linux kernels up to v2.6.11. For the list of environment-specific file locking system calls used by the certificate generator, see Ssl::Lock::lock(). > Since squid is being used in couple locations as a security software it > would be good for security admins to be able to have some history logs. The generated certificate database is just an optimization/cache. Logging certificate cache operations would probably be as useful/useless as store.log is for the HTTP cache. It would be good to discuss and target some specific use cases before designing where and how to log certificate operations. Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev