[Bcc:ed to -security, please followup on -arch]

The ptrace(2) syscall, which is mainly used by gdb(1), implements some
of its functionality by faking up a struct uio and making calls into
the guts of procfs(5). This is why four of the source files that make
up procfs(5) are listed as "standard" rather than as "optional procfs"
in src/sys/conf/files.

The funny thing is that there's no reason for the ptrace(2) code to
call any procfs(5) code, since the functions it calls are actually
(mostly) wrappers around MD code, with some extra error checking. The
errors they check for are of the kind that Can't Happen[tm] when these
wrappers are called from ptrace(2) because ptrace(2) already checks
for them before calling the procfs(5) code.

For instance, all procfs_domem() does is check that uio->uio_resid is
non-zero (ptrace() sets it to sizeof(int)) and that the requesting
process is allowed to debug the target process (already checked by
ptrace()), and then pass its arguments unmodified to procfs_rwmem().

What I propose to do is:

 - move procfs_rwmem() from src/sys/fs/procfs/procfs_mem.c into
   src/sys/kern/sys_process.c or some other convenient location where
   both ptrace(2) and procfs(5) can access it (and also move its
   prototype to a convenient header file).

 - rewrite the remaining cases (PT_{GET,SET}{,DB,FP}REGS) to call
   procfs_{read,write}_regs() (which is implemented in each port's
   procfs_machdep.c) directly, instead of calling procfs_do*().

 - make the permission checks at the top of ptrace(2) slightly more
   aggressive (immediately return EINVAL if the target process is a
   system process; immediately return EPERM if p_candebug() returns
   non-zero and an operation other that PT_TRACE_ME was requested).

This will slightly reduce the size (and speed up the build) of a
procfs(5)-less kernel.

I would also like to implement a kernel option named NO_DEBUGGING (or
something similar) which replaces ptrace(2) and the MD parts of
procfs(5) with stubs that simply return EINVAL or EPERM, thus making
it impossible to use gdb(1), truss(1) and similar tools; I will also
change procfs(5) to not list debugging-related files (ctl, regs etc.)
when loaded by a kernel that was built with NO_DEBUGGING.

Comments? Flames?

DES

-- 
Dag-Erling Smorgrav - desofug.org
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]