Date: Tue, 30 Dec 2014 15:07:10 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Disabling ptrace Message-ID: <20141230140709.GA96469@stack.nl> In-Reply-To: <20141230111941.GE42409@kib.kiev.ua> References: <20141230111941.GE42409@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 30, 2014 at 01:19:41PM +0200, Konstantin Belousov wrote: > The question about a facility to disable introspection functionality > (ptrace etc) for a process was asked several times. The latest query > made me actually code the feature. Note that other systems, e.g. Linux > and OSX, do have similar facilities. > Patch is below, it provides two new procctl(2) requests. > PROC_TRACE_ENABLE enables or disables tracing. It includes core > dumping, ptrace, ktrace, debugging sysctls and hwpmc. > PROC_TRACE_STATUS allows to get the tracing state. > Most interesting question is how should disabling of trace behave > with regard of fork and exec. IMO, the right model is to protect > access to the _program_ address space, which translates to inheritance > of the attribute for fork, and reenabling the tracing on exec. I agree. I imagine this will be useful for programs like ssh-agent, to protect their unlocked key material. This is also what Linux provides, and it is simpler than this patch: prctl(PR_SET_DUMPABLE) lets a process make their issetugid() equivalent return true, including preventing tracing by unprivileged users. You could call that unification a hack. > On the other hand, I understand that some users want to inherit the > tracing disable on exec, so there are PROC_TRACE_SET_DISABLED and > PROC_TRACE_SET_DISABLED_EXEC, the later makes disable to be kept after > exec. This is apparently meant to protect a whole process tree as a hardening measure, or instead of PROC_TRACE_SET_DISABLED if it is undesirable to modify the program with key material. > Note that it is trivial for root on the host to circumvent the feature. I'd prefer if root can still trace normally, without needing any hacks. Philosophically, FreeBSD should serve the system administrator first and only then the application programmer. Also, the debugging facilities may be needed to debug FreeBSD itself (e.g. procstat -k), not just the application. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141230140709.GA96469>