> a. what is svnd? (srry :x) The Vnode disk driver. See man vnd.
> 2. what fs is mountable and dynamic in size? > your suggesting mounting each seperate users home on login, though this > would (based on all of my knowledge of current filesystems) that it > would have to be of a static size. for quotas this would be fine, but > id imagine a lot of people wont like this. Its not dynamic. You have to decide on a fixed size. You can probably resize it with growfs on demand. As for some time, the size limit was on 8,2G, but according to a documentation that was posted at undeadly.org, this limitation doesn't exist anymore. I haven't verified it myself, though. http://www.backwatcher.org/writing/howtos/obsd-encrypted-filesystem.html http://geektechnique.org/index.php?id=84 I don't know of any way to keep stuff encrypted transparently and using the filesystem as usual without leaking information. > c. your going to make a passwd change transparent as well? not many do, > but i for one do change my password every 90 days, and having the key for > my home re-keyed/re-encrypted im not going to remember. The idea is to use a random 16 byte key for the disk encryption, which is itself encrypted with your login password. Thus you can pass your password on login and have your $HOME mounted without issuing any additional commands. You can change your password anytime, just don't forget to do that for your disk key as well. Nobody will modify passwd because of that stuff. > 4. must ensure not to umount if im still logged in? BUT i for one do not > want my home to remain mounted if someone has su'd as me. and how will > this work if someone sets utmp/wtmp o-rwx. su uses login_cap, thus it should be handled like any other login for this kind of users. As of utmp: root is looking it up, so this should be no problem at all. > ... i disavowed any questions of root access, as per the theory of; if > homes are encrypted, root should not require access to homes, and thus > will never be used on *public* boxes (shell companies in particular) Disk encryption will make most sense on notebooks and backup machines, where you want protection in case the device is stolen. As long as you're logged in, everybody can access the directories due to the permissions set. > oh, where is the code you have 'now' that you said? id really like to view By now, I only have the binary for key-creation, key-encryption and password changing on the key. I'd like to wait for some more feedback before I do more. Be patient. > > > On Thu, 1 Dec 2005 01:48:12 +0100 (CET), [EMAIL PROTECTED] wrote: >> Hi guys, >> >> I thought about a way of de-/encrypting home-directories transparently >> to >> users. I've got a vague idea how to realize this in a reasonable way: >> >> * Generate a key, associate it with a new svnd-image, prepare the image >> * Encrypt the key with the users login password, store it in /home >> * On login, decrypt the key with the password >> * Pass the decrypted key to vnconfig and mount the image on $HOME >> >> This has some consequences, like >> - creating a new login facility login_decrypt (or sth. similar) >> - writing a program for keyfile/image generation and password changing >> - modify vnconfig to read keys from other sources than stdin >> >> Since I already got some code, it might be smart to ask now for some >> feedback before heading into a completely wrong direction. >> There are probably better ways to accomplish this, so generally opinions >> regarding the issue would be cool.
