ar *path): unlink(2) wrapper
* int sandbox_open(const char *path, int flags, mode_t mode, cap_rights_t
*rights): open(2) wrapper
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9
Hey All,
This is a brief update.
On Tue, Oct 17, 2017 at 05:01:33PM +, Shawn Webb wrote:
> Known Issues
>
>
> Enabling the sandbox while having Tor configured in transparent proxy
> mode is currently broken. We are researching what causes the breakage.
> Chanc
ngerprinting changes as
different alternate implementations of various OS components (heap
implementations, LibreSSL versus OpenSSL, etc.) affect OS
fingerprinting at an application level (via JS, content rendering, or
otherwise.)
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ifi
. in the parent process. I'm trying to get that enabled
> for mozjemalloc in H2 2019.
>
> In conclusion, while it's possible hardened_malloc could provide some
> small security increase over mozjemalloc, the gap is much smaller than
> it was when I advocated for allocator
on altogether. Without doing so, the curl project seems
unwilling to make the prohibition a choice that can be made at runtime
by the user, even.
Please remember that these kinds of things have real and tangible
human consequences. Some of our users remain in harms way to this day
because of this.
e and understand the many nuances of this
particular problem, it is one that is indeed difficult to solve.
Are there other commonalities between "infoleaky" deployments that
could be improved? It seems to me that outright prohibition should be
a method of last resort. Are we already
