On 10/15/07, Trevor Highland <[EMAIL PROTECTED]> wrote:
> Alon,
>
> The documentation you are looking for can be found in the kernel source with
> the following path Documentation/keys.txt. The keyutils package is an
> interface to the kernel key ring which stores keys. The keyring was
> designed for keys that are cached for file systems and other os services.
> It is necessary to keep the key in memory unless a TPM is used, but it is
> protected with sufficient access permissions. Here is what the kerenl
> documentation says about access permissions.
$ keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
209703985 --alswrv 1000 -1 \_ keyring: _uid.1000
178553112 --alswrv 1000 449 \_ user: 107b50e092b00995
$ keyctl pipe 178553112 | hexdump -C
00000000 04 00 01 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000270 00 00 00 00 10 00 00 00 b4 05 00 00 31 30 37 62 |............107b|
00000280 35 30 65 30 39 32 62 30 30 39 39 35 00 70 6b 63 |50e092b00995.pkc|
00000290 73 31 31 00 00 00 00 00 00 00 00 00 00 00 96 00 |s11.............|
<snip>
This key was created using ecryptfs-manager... And I can read the
contents of it, as any other usermode application. So my conclusion is
that it is unsecured.
Maybe ecryptfs-manager does not use the key interface correctly, and
it should set the permission of the key so that it cannot be viewed by
the user, having the cryptfs kernel mode extract the contents and send
it via the netlink socket?
Alon.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
eCryptfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
