Date: Sat, 6 Oct 2001 10:50:19 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: Removing ptrace(2)'s dependency on procfs(5) Message-ID: <Pine.NEB.3.96L.1011006103450.66473E-100000@fledge.watson.org> In-Reply-To: <xzpitdsrhog.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Oct 2001, Dag-Erling Smorgrav wrote:
> Robert Watson <rwatson@FreeBSD.ORG> writes:
> > I'm leaning towards (2): debugging simply doesn't apply, and should be
> > checked for by the routines. If it were a security check, that might
> > imply that you could change the policy to allow such debugging, which you
> > can't. Since we would still like ESRCH to be returned for processes in
> > jail when attempting to attach to system processes, that means that the
> > security check should go first, and the P_SYSTEM check should go second.
>
> Sure, but doesn't prison_check() take care of ESRCH? I can add the
> P_SYSTEM check *after* the prison_check() call in p_candebug():
The question I'm trying to address here is a bit more subtle than that:
it's not a question of what we can do, but what we should do. Generally
speaking, you might choose to consider security checks of this sort in the
following way: there's a certain scope of "valid" requests, and the set of
valid requests is going to be limited by a security function. Because
there are a number of security failure modes ("you can't even see that it
exists" vs. "you can see it, but not touch it"), the ordering and
composition of the security checks can be complex. But the question I'm
trying to look at here is whether or not, fundamentally, the P_SYSTEM
check is a security check.
Right now, my leaning is that it is not: checking P_SYSTEM is a validity
check because ptrace() and procfs are both definined as allowing the
debugging of normal user processes, not system processes. I.e., if you
had a system without a security model, you still wouldn't allow debugging
of system processes using the user debugger interface. Since the goal of
p_candebug() is to impose the general security debugger-related policy,
not perform validity checks on arguments, that suggests that the P_SYSTEM
check should be present in the service implementation (proc_rwmem() or
whatever it's going to be called). Now, that doesn't mean that it
shouldn't *also* exist in p_candebug(). You can easily imagine a system
security policy that did revolve around protecting system processes--for
example, the fact that the jail code restricts the visibility of such
processes. Rather than having that implicit on jail membership, it could
be explicit, in the form:
int
p_cansee(...)
...
if (p->p_flags & P_SYSTEM)
return (ESRCH);
...
However, that suggests that if you want to have one in p_candebug(), it
should be redundant, and purely an addition to the one in proc_remem().
In fact, I would argue that if there was a P_SYSTEM check in p_candebug(),
it should look like this:
int
p_candebug(...)
...
if (p->p_flags & P_SYSTEM)
return (EPERM);
...
Which is not the desired EINVAL return value. So my opinion is that the
P_SYSTEM check should remain in the individual debugging interfaces, and
that if redundancy is OK, consider adding a P_SYSTEM->EPERM check in
p_candebug().
Interestingly, BTW, this is similar to the issue of read-only mounting of
file systems. Right now, my opinion is that if a file system os mounted
read-only, that's not a security protection. That's a syntactic function
of the mount/file system service. So it should always return EROFS,
rather than EPERM, and isn't abstracted into the general security code
(via vaccess(), vaccess_acl_posix1e(), vaccess_mac(), et al). An argument
to support this is that this is the flag used at the file system level as
a validity check to prevent writing to read-only underlying media.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011006103450.66473E-100000>