Date: Sat, 3 Jan 2015 13:37:33 +0000 From: Robert Watson <rwatson@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Disabling ptrace Message-ID: <179DAA4D-3526-446C-A0A2-9F7DA137293F@FreeBSD.org> In-Reply-To: <20150102171314.GS42409@kib.kiev.ua> References: <20141230111941.GE42409@kib.kiev.ua> <alpine.BSF.2.11.1501020906300.69379@fledge.watson.org> <20150102171314.GS42409@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > Also, I am puzzled by reference to an async context. > Could you provide explicit examples where we do such tracing ? It=E2=80=99s 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 =E2=80=94 but we don=E2=80=99t = 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 =E2=80=94 specifically, for the audit = trail =E2=80=94 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 =E2=80=94 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. I=E2=80=99m OK with putting the flag on the process, but frequently the = process credential is where we stick security-related subject/object = flags... Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?179DAA4D-3526-446C-A0A2-9F7DA137293F>