Currently,... when passdev is given a device:path where the device is
already mounted somwhere it fails.

It would be nice that it doesn't fail in this case but bind-mount the
device readonly.
This would also be important I you agree my following proposals where
I ask if we could change cryptsetup, that all keyscripts should/must
support device:path-syntax (see also this thread
http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-December/002376.html)

I'm not sure if this works when the device was originally mounted rw,
but I think it does.
I'd also suggest to do the bind-ro-mounting instead of just reading
the file, because this would change access time which is perhaps
monitored or have other influences on a rw-mounted filesystem.

I think I'd need help with these changes ;)

Thanks,
Chris.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

FYI,... I'm already working on this ;-)

Chris.

Hey Christoph,

you wrote in another mail, that you're working on this. any news about
that?

greetings,
 jonas

No not recently.

I guess we should first think about how the future of keyscripts and
passdev looks like.

You know that I've often predicted that they are likely to get rather
more complicated than simpler, especially with "modern" stuff like
smartcards, fingerprint sensors (which all need their own driver
framework), etc.


One way is of course chaining of multiple keyscripts,... but I doubt
that this is the right way to go.



So personally I'd suggest something like the following:
- stick with "only one keyscript" per mapping-entry (better would be the
name keyloader or something like this, IIRC it does not have to be a
script, right?)

- specify a way to put arbitrary options in crypttab

- no longer provide a dedicated "passdev" script, but make this a helper
tool, which can be used by other keyscripts to load files.
Reasonable options (see above would be deivce= and pathname=)


Why do I tell all this,... well I guess the future of passdev should be
that of a helper tool (perhaps even a new package, that cryptsetup
depends on) with about the following interface:
param1 => pathname of the file to read
param2 => optionally, a device where the fs is located, if not take /
param3 => a timeout how long the program may run (including waiting for
the device to appear perhaps also two separate params for this)
stdout => the read file
stdin => ignored
stdrr => error messages

It should be totally read-only,noexec,noatime etc. pp.
The problem here is, some filesystems change the fs per defaul even when
mounted ro (all ext234 can do this), so one would have to add specific
mount options depending on the fs-type.

If the device is already mounted, it should use that. Best would be of
course to bind mount then,.. with ro,noexec,etc (as above). But IIRC;
bind-mounting simply uses the same options as the original mountpoint.


Nevertheless,... I personally do not see much pressure in that issue...
it's just a nice functionality... and we have many issues which can be
security critical.


Best wishes,
Chris.

Hey.

I recently had a look at passdev and found several other ideas for
improvements.

Not sure if I have time to look into these, and I'd anyway just put an
effort into it if it's clear that such changes were desired and the
work wouldn't be wasted.




I) The aforementioned support for already mounted devices/filesystems

Actually I'm not so sure whether that wouldn't have any undesired side
effects.
Maybe the idea with bind,ro mounting would work.




II) Insecure mounting in /tmp/passdev.XXXXXX
Right now, passdev mounts the fs at /tmp/passdev.XXXXXX.

While that directory itself has 0700 permissions, once mounted it will
get the permissions of the / of the fs, which are typically 0755.
So any user could possibly access parts of that filesystem.

I think it would be enough if we'd mount the fs at, e.g.:
/tmp/passdev.XXXXXX/mnt
That way the 0700 of /tmp/passdev.XXXXXX would stay effective.




III) Can we prevent that other tools go into the mountpoint and lock
it?
Think of things like rkhunter or so, which search through files,
possibly even opening them.
That may make unmounting fail.
But not sure whether we can do anything against that.




IV) As mentioned already, for several filesystems, mounting them ro
does not really mean they're never written to.
E.g. btrfs would need norecovery,... ext might use the lazy inode init
when mounted ro (not sure if it really did that).




V) Max filesize to read
One should perhaps impose a maxmimum size of a keyfile to read.
I don't know... maybe 1MiB... should be enough for all times any
reasonable key would be just a fraction thereof.
And obviously, don't print *anything* to stdout, if the limit was
exceeded.




VI) Only read from regular files and don't follow symlinks over device
borders




VII) Improving the interface
Right now we have device:pathname[:timeout].
That has the disadvantage that we cannot use devices/pathnames
containing ":", unusual, sure.

What about the following:

1 arg:
	- if arg contains ":" use the old way
	- if arg doesn't contain colon: read file from the file
          hierarchy
          without any mounting
2-3 args:
        - arg #1 = device
        - arg #2 = pathname
        - arg #3 = optional timeout

Or even better would be to use proper --option=value switches, so one
could extend the whole thing in the future without causing breakage.




Well, so much for the records ;-)


Chris.

One further idea for future work on passdev



VIII) Not blindly trying through fstypes in the mount

Right now it goes through a fixed list and tries them one after
another.
In principle that works, but it can leave ugly messages in the kernel
log, e.g.:
Sep 18 01:33:53 heisenberg kernel: EXT4-fs (sdb2): VFS: Can't find ext4 filesystem
Sep 18 01:33:53 heisenberg kernel: EXT4-fs (sdb2): VFS: Can't find ext4 filesystem
Sep 18 01:33:53 heisenberg kernel: EXT4-fs (sdb2): VFS: Can't find ext4 filesystem
Sep 18 01:33:53 heisenberg kernel: FAT-fs (sdb2): bogus number of reserved sectors
Sep 18 01:33:53 heisenberg kernel: FAT-fs (sdb2): Can't find a valid FAT filesystem

until it finally works when finding the right one:
Sep 18 01:33:53 heisenberg kernel: BTRFS info (device sdb2): disk space caching is enabled
Sep 18 01:33:53 heisenberg kernel: BTRFS info (device sdb2): has skinny extents

One idea would be to use libblkid.


I do however quite like the idea of having a fixed list of types which
are considered.