Skip site navigation (1)Skip section navigation (2)
Date:      01 Oct 2001 13:27:13 +0200
From:      Dag-Erling Smorgrav <des@ofug.org>
To:        audit@FreeBSD.org
Cc:        Robert Watson <rwatson@FreeBSD.org>, Jordan Hubbard <jkh@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: cvs commit: src/sys/fs/pseudofs pseudofs.c pseudofs.h pseudofs_vnops.c
Message-ID:  <xzpzo7biory.fsf@flood.ping.uio.no>
In-Reply-To: <20010930203751.A52548@xor.obsecurity.org>
References:  <Pine.NEB.3.96L.1010930214407.69480D-100000@fledge.watson.org> <xzp8zewjch0.fsf@flood.ping.uio.no> <20010930203751.A52548@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway <kris@obsecurity.org> writes:
>                                                      [...]  If your
> changes bring about increased code transparency and simplicity, then
> it will probably result in a net security improvement, but any change
> to procfs has the potential to bring with it security vulnerabilities;
> hence the request for a code audit.

Well, pseudofs is in the tree, and linprocfs is using it, so audit
away.  I don't think there will be any more earth-shattering commits
to pseudofs; all of the infrastructure I need to finish converting
procfs is now in place, so from now on it'll be bug fixes and
performance improvements (e.g. in the vnode cache).

One API change I may still make is the way process-dependent nodes are
defined.  You can currently only have process-dependent directories,
but it may make sense in some applications to have process-dependent
files or symlinks that are not contained in a procdir.  It's not a
major change, and should only affect pfs_lookup() and pfs_readdir().

I think pseudofs has all the p_canxxx() calls it needs, though it's
hard to tell as there's no documentation for p_canxxx().  There are
some edge cases where one might want to add checks, but they're only
reachable through application bugs (such as adding a process-dependent
and forgetting to mark it as such - its visibility callback won't get
called because pseudofs doesn't have a target process to check
against).  If there are any serious privilege checks missing, they're
special-case checks that belong in the application code (linprocfs,
procfs) and not in pseudofs itself.

I've verified empirically that jailed processes only see procfs nodes
for processes within the same jail, and that file descriptors are
revoked as they should when the process they're associated with dies.

I'm also quite certain pseudofs is not vulnerable to the kind of
attacks described in SA-00:55 and SA-01:77.  I'd welcome any proof to
the contrary.

I'll submit patches for the procfs conversion to -audit when I'm done,
but unless Kris or Robert is willing to do the job, I doubt anyone
will bother reviewing them, and I'm not going to sit and wait forever.

DES
-- 
Dag-Erling Smorgrav - des@ofug.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpzo7biory.fsf>