freebsd-arch Digest, Vol 365, Issue 2

Vladislav Soldatov vsoldatov at gmail.com
Tue May 18 19:13:12 UTC 2010


On Wed, Apr 28, 2010 at 4:00 PM, <freebsd-arch-request at freebsd.org> wrote:

> Send freebsd-arch mailing list submissions to
>        freebsd-arch at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> or, via email, send a message with subject or body 'help' to
>        freebsd-arch-request at freebsd.org
>
> You can reach the person managing the list at
>        freebsd-arch-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-arch digest..."
>
>
> Today's Topics:
>
>   1. Re: New "scallhook" feature. Is is OK to create a proposal?
>      (Jeremie Le Hen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Apr 2010 18:54:31 +0200
> From: Jeremie Le Hen <jeremie at le-hen.org>
> Subject: Re: New "scallhook" feature. Is is OK to create a proposal?
> To: Alexander Churanov <alexanderchuranov at gmail.com>
> Cc: freebsd-arch at freebsd.org
> Message-ID: <20100427165431.GQ34466 at felucia.tataz.chchile.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Alexander,
>
> On Tue, Apr 06, 2010 at 05:27:29PM +0400, Alexander Churanov wrote:
> > About me:
> >
> > I am software engineer, currently working in Cisco Systems, specializing
> in
> > C/C++/UNIX. My additional interests are software quality and security. I
> am
> > a port maintainer for devel/boost-* and was participating in extending
> > syscons driver, until the project was superseded by syscons rewrite by Ed
> > Schouten.
> >
> > About Vladislav:
> > Vladislav is a PhD of computer science, has experience with developing in
> C
> > and C++ for FreeBSD.
> >
> > Before writing the full proposal on the wiki, I'd like to receive the
> first
> > approval.
>
> I don't know what you intend to do after Robert's reply but if you are
> seeking a kernel-level security improvement to work on, I suggest to
> look at porting PaX into FreeBSD.
>
> Regards,
> --
> Jeremie Le Hen
>
> Humans are born free and equal.  But some are more equal than others.
>                                            Coluche
>
>
> ------------------------------
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>
> End of freebsd-arch Digest, Vol 365, Issue 2
> ********************************************
>
It seems to me that discussion on the new "scallhook" feature,
proposed by my friend Alexander Churanov, has somehow frozen.

We propose the following possible solutions to the problems, mentioned
by Robert Watson.

We propose to create a special procedure to control the "identity" of
the object, to which the given indirect argument is pointing. For
example, we can calculate the hash code of the string, that represents
absolute path to the resource, before the policy checks done by the
scallhook's modules are performed, and store it somewhere in the
kernel space. When the actual system call is made, we compute it again
and compare with the previously saved one. It is evident, that this
procedure is not able to prevent the substitution of the object, for
example, associated with the symbolic link. Nonetheless, it allows to
"spot" indirect argument substitution and raise an error. Yes, this
approach is intrusive and requires kernel source code changes.

We prefer substitution detection over locking, because this allows
policies to be implemented in user-space processes (for flexibility),
as well as implemented in loadable kernel modules (for performance).
While permitting implementation of the the policy check procedures in
languages other than C and easy debugging, this approach prevents
concurrency vulnerabilities by performing the argument identity check
in kernel.

Recently Jeremie Le Hen has mentioned a possibility of porting PaX
from Linux to FreeBSD. Our aim is not just to port something to
FreeBSD, but to create a general mechanism for secure system call
interposition. PaX has a different functionality and can't be used to
implement policy check logic of any kind or detect argument
substitution in syscall wrappers.


More information about the freebsd-arch mailing list