[pkg-cryptsetup-devel] Bug#509068: cryptsetup: improving passdev

[Christoph Anton Mitterer]

Control: retitle -1 : cryptsetup: improving passdev

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.