Date: Sat, 3 Jan 2015 16:25:35 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@freebsd.org Subject: Re: Disabling ptrace Message-ID: <20150103142535.GW42409@kib.kiev.ua> In-Reply-To: <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> References: <20141230111941.GE42409@kib.kiev.ua> <alpine.BSF.2.11.1501020906300.69379@fledge.watson.org> <20150102171314.GS42409@kib.kiev.ua> <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 03, 2015 at 01:37:33PM +0000, Robert Watson wrote: > On 2 Jan 2015, at 17:13, Konstantin Belousov <kostikbel@gmail.com> wrote: > > > WRT putting the trace-disabled indicator into the credentials, instead > > of just having it as a process attribute, I am not sure that this is > > useful thing. Do you propose to modify existing ucred for the process, > > effectively applying the notrace policy to the whole set of processes > > sharing the credential, or do COW for ucred on disable ? If not COW, > > then the set of the affected processes is somewhat random and too wide. > > If COW, I do not see much practical difference with the per-process > > bit, esp. due to the execve(2) handling. > > > > Also, I am puzzled by reference to an async context. > > Could you provide explicit examples where we do such tracing ? > > It???s less about what we do do, and more about what we perhaps should be doing. I had two things vaguely in mind, neither of which is a perfect match: > > (1) Normally, we expose the data from synchronous read(), write(), send(), and recv() operations using ktrace ??? but we don???t currently do this for asynchronous I/O calls. We likely should, in which case I was pondering which of the asynchronously available bits of state we might want to use for it. In principle, we have both the calling process and credential available, so there, the process would be fine. > > (2) For other kinds of tracing ??? specifically, for the audit trail ??? we make use of saved credentials in a number of cases, and store audit-related filtering data (not so dissimilar from a no-trace flag in some ways) in the credential for this reason. While you are not proposing limiting auditing using this process flag, I think there are a number of structural similarities here that could suggest a similar approach. > > In general, we had always planned to allow auditing of far more asynchronous events than we currently do ??? e.g., firewall events triggered asynchronously by system-call behaviour. We also had loose plans to allow auditing of NFS-originated RPCs, although those are arguably fairly synchronous and not so dissimilar to system calls in various ways. Isn't allowing a process to exempt itself from aduting a real security bug ? > > I???m OK with putting the flag on the process, but frequently the process credential is where we stick security-related subject/object flags... Should I interpret the statement as agreement, in principle, with the patch ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150103142535.GW42409>