From owner-freebsd-questions@FreeBSD.ORG Sun Jan 18 21:57:42 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A288106564A for ; Sun, 18 Jan 2009 21:57:42 +0000 (UTC) (envelope-from ilikefbsd@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id C43238FC23 for ; Sun, 18 Jan 2009 21:57:41 +0000 (UTC) (envelope-from ilikefbsd@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate02.web.de (Postfix) with ESMTP id 78DA9F90F47E; Sun, 18 Jan 2009 22:57:40 +0100 (CET) Received: from [78.52.48.166] (helo=[192.168.1.118]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LOfeG-0007NU-00; Sun, 18 Jan 2009 22:57:40 +0100 Message-ID: <4973A5D2.6000108@web.de> Date: Sun, 18 Jan 2009 22:57:38 +0100 From: Marco User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Roland Smith References: <497092C6.7030905@web.de> <20090116175318.GA73625@slackbox.xs4all.nl> In-Reply-To: <20090116175318.GA73625@slackbox.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ilikefbsd@web.de X-Sender: ilikefbsd@web.de X-Provags-ID: V01U2FsdGVkX19JTwi+3ri1L7dZzharGCnLU6gh+S1tE3HY9YGr qPxxUHAU3MmT3bBv7cUbDZ21ilEiW6anXRFhMiA5iYOd9Ai1gH StxCKlOJI= Cc: freebsd-questions@freebsd.org Subject: Re: Runtime de/encryption X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 21:57:42 -0000 First, thanks Roland. >On-disk encryption is not meant to secure access on a running machine. This is very true. And the reason for my thoughts on that topic. > I don't think there is something like that can be easily done. You'd > have to alter the semantics of systems calls like open(2) and read(2) to use > passwords. Changing the syscall's is also an interesting idea. That however would basicly change the host system in it's inner workings. Now, it would imply some changing of kernel related code base, with decision/distinguish on type of files. And in a case of encrypted file to use the beforehand added open_enc()/close_enc() ... syscall(s). Still this would make it possible to work with normal files, but also apply the functionality of runtime encryption. In difference to an extra layer of fs this possibly would be very unportable on the first thought.Nevertheless, i like the idea. Best regards, Marco Roland Smith wrote: > On Fri, Jan 16, 2009 at 02:59:34PM +0100, Marco wrote: > >> Hello List, >> >> i'am using the geom framework for quite a time. I'am happy about >> gbde/geli implementations(beside the race condition in geli) however, i >> wonder since some time, as the data may get >> exposed on a running server(as the partitions decrypted) >> > > On-disk encryption is not meant to secure access on a running machine. > > File and directory contents are only decrypted in memory, not on disk > when you read them. You should use normal file permissions and possibly > ACL's to restrict access to mounted filesystems. > > There are of course data structures in the kernel that contain decrypted > information about the volume. But if an attacker can grab that info from > a running kernel you've got bigger problems... > > >> is there a way >> to do some kind of runtime de/encyrption, with keys? so that only >> special users with the right handle can encrypt or decrypt data? so >> talking about another filesystem layer... >> > > I don't think there is something like that can be easily done. You'd > have to alter the semantics of systems calls like open(2) and read(2) to use > passwords. > > Roland >