On Tue, 19 Feb 2002, cyphrpnk wrote: > unfortunately an examination of the source reveals no hmac being maintained on > the file used as a vnode mounted filesystem, gives this same vunerability. > (its easily resolved by taking an external hmac(via samhain,demairc,tripwire, > sha1 etc,) during unmount and then checking same prior to mount > various other solutions are discussed in the linux paper posted to bugtraq
True. Whether or not this is a problem depends on your threat model, of course. A wrapper script to vnconfig and mount/umount which records a hash might make an acceptable workaround, though it'd include a race condition. > the 8.4 gb limitation is a limitation of mkfs when working through > a vnd mounted files system.(anything larger breaks badly). You're still referring to OpenBSD here? I hadn't come across that problem, since I've been using smaller disks. There was a patch to OpenBSD in October to make vnd work with files up to 1TB: http://www.monkey.org/openbsd/archive/bugs/0110/msg00072.html This may or may not solve the problem. I can't find any reference to limitations within newfs. > In addition...a sudden power down on this type of filesystem(encrypted, VND > mountea)d will damage the resulting structure so that fsck WILL NOT work > on it. I've had power failures while using mounted encrypted loopbacks which have recovered fine with fsck. Haven't tested it extensively. Is this a problem with the current release? -- mailto:[EMAIL PROTECTED] F289 2BDB 1DA0 F4C4 DC87 EC36 B2E3 4E75 C853 FD93 http://zem.squidly.org/weblog/ "..I'm invisible, I'm invisible.."
