| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 11 Jan 2009 22:36:41 -0600 From: Robert Hancock <hancockr@...w.ca> To: joseluismarchetti@...oo.com.br CC: Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org Subject: Re: How to access a regular file from within a module ? Jose Luis Marchetti wrote: >> You don't generally get to do this. What are you >> actually trying to achieve ? > > Thanks for asking, there are two scenarios, the first one it would be to save an ethernet mac address, I got already emails with some work arounds for this. The other scenario is a little bit more complicated: > > The system I am working now ( Kernel drivers + User applications ) performs cryptographic operations and it has a regulatory constraint: the user application have to undergo (expensive) certification everytime it is changed, but that is only true if the user application have access to the cryptographic keys, imagine a i++ is missing in the code, then we have to undergo the expensive certification for that. > To avoid that I am trying to isolate the keys ( about 30 X 128bit keys, some of the keys chance everytime they are used ) and cryptographic algorithm from the application and putting them into the kernel so the application can not access that. Well you would say, saving the keys into a file is not a good security measure as it is accessible, the trick is that before saving the key into the file the kernel would encrypt the keys with another key ( KEK- Key Encryption Key ) and this KEK is stored into non volatile register inside the processor, so although the file is accessible it is encrypted. > In this scenario the user application would request encryption/decryption services from the kernel, but it would never pass the Key to be used during the operation, it would pass a Key Id, like this: encrypt this data using key number 7 and Key number 7 is stored in a file ( encrypted ) the kernel could read. > OK, some would say, the user application could read the key file and passed the encrypted key into the kernel function, the kernel would decrypt the encrypted key and do the operation, which is fine, but some of those keys change at every operation, so they have to be re-stored into the file at every operation, it would be nice to have it done by the kernel. One big problem with file access in the kernel is that all the file operations require a process context - they need a process to stick the file descriptor into, to determine access permissions, etc. If you just start calling file operations from inside the kernel you're essentially stealing whatever process you're being called from's context for these operations, which is unlikely to be a good idea. Not to mention, that accessing files from inside the kernel usually means the kernel enforces a policy on file naming/locations, and putting that sort of policy in the kernel is usually frowned upon. In the case you're describing I'm not sure why you couldn't just store the keys in encrypted form inside the user app and have it write them back out when they change, instead of making the kernel do it.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists