)]}' { "log": [ { "commit": "6a3fd92e73fffd9e583650c56ad9558afe51dc5c", "tree": "d65917432ffd0e6223dab3500819205433de22bd", "parents": [ "f66e883eb6186bc43a79581b67aff7d1a69d0ff1" ], "author": { "name": "Michael Halcrow", "email": "mhalcrow@us.ibm.com", "time": "Tue Apr 29 00:59:52 2008 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Tue Apr 29 08:06:07 2008 -0700" }, "message": "eCryptfs: make key module subsystem respect namespaces\n\nMake eCryptfs key module subsystem respect namespaces.\n\nSince I will be removing the netlink interface in a future patch, I just made\nchanges to the netlink.c code so that it will not break the build. With my\nrecent patches, the kernel module currently defaults to the device handle\ninterface rather than the netlink interface.\n\n[akpm@linux-foundation.org: export free_user_ns()]\nSigned-off-by: Michael Halcrow \u003cmhalcrow@us.ibm.com\u003e\nAcked-by: Serge Hallyn \u003cserue@us.ibm.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "f66e883eb6186bc43a79581b67aff7d1a69d0ff1", "tree": "9fc1fb65586ff334a1f8c1afb9a43edf077d338f", "parents": [ "8bf2debd5f7bf12d122124e34fec14af5b1e8ecf" ], "author": { "name": "Michael Halcrow", "email": "mhalcrow@us.ibm.com", "time": "Tue Apr 29 00:59:51 2008 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Tue Apr 29 08:06:07 2008 -0700" }, "message": "eCryptfs: integrate eCryptfs device handle into the module.\n\nUpdate the versioning information. Make the message types generic. Add an\noutgoing message queue to the daemon struct. Make the functions to parse\nand write the packet lengths available to the rest of the module. Add\nfunctions to create and destroy the daemon structs. Clean up some of the\ncomments and make the code a little more consistent with itself.\n\n[akpm@linux-foundation.org: printk fixes]\nSigned-off-by: Michael Halcrow \u003cmhalcrow@us.ibm.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "b7c6ba6eb1234e35a74fb8ba8123232a7b1ba9e4", "tree": "672c08c95229a6ac242ab12a5195dceddb0f3127", "parents": [ "4f84d82f7a623f8641af2574425c329431ff158f" ], "author": { "name": "Denis V. Lunev", "email": "den@openvz.org", "time": "Mon Jan 28 14:41:19 2008 -0800" }, "committer": { "name": "David S. Miller", "email": "davem@davemloft.net", "time": "Mon Jan 28 15:08:07 2008 -0800" }, "message": "[NETNS]: Consolidate kernel netlink socket destruction.\n\nCreate a specific helper for netlink kernel socket disposal. This just\nlet the code look better and provides a ground for proper disposal\ninside a namespace.\n\nSigned-off-by: Denis V. Lunev \u003cden@openvz.org\u003e\nTested-by: Alexey Dobriyan \u003cadobriyan@openvz.org\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n" }, { "commit": "cd40b7d3983c708aabe3d3008ec64ffce56d33b0", "tree": "0d6fe9cfd2f03fdeee126e317d4bfb145afc458d", "parents": [ "aed815601f3f95281ab3a01f7e2cbe1bd54285a0" ], "author": { "name": "Denis V. Lunev", "email": "den@openvz.org", "time": "Wed Oct 10 21:15:29 2007 -0700" }, "committer": { "name": "David S. Miller", "email": "davem@davemloft.net", "time": "Wed Oct 10 21:15:29 2007 -0700" }, "message": "[NET]: make netlink user -\u003e kernel interface synchronious\n\nThis patch make processing netlink user -\u003e kernel messages synchronious.\nThis change was inspired by the talk with Alexey Kuznetsov about current\nnetlink messages processing. He says that he was badly wrong when introduced \nasynchronious user -\u003e kernel communication.\n\nThe call netlink_unicast is the only path to send message to the kernel\nnetlink socket. But, unfortunately, it is also used to send data to the\nuser.\n\nBefore this change the user message has been attached to the socket queue\nand sk-\u003esk_data_ready was called. The process has been blocked until all\npending messages were processed. The bad thing is that this processing\nmay occur in the arbitrary process context.\n\nThis patch changes nlk-\u003edata_ready callback to get 1 skb and force packet\nprocessing right in the netlink_unicast.\n\nKernel -\u003e user path in netlink_unicast remains untouched.\n\nEINTR processing for in netlink_run_queue was changed. It forces rtnl_lock\ndrop, but the process remains in the cycle until the message will be fully\nprocessed. So, there is no need to use this kludges now.\n\nSigned-off-by: Denis V. Lunev \u003cden@openvz.org\u003e\nAcked-by: Alexey Kuznetsov \u003ckuznet@ms2.inr.ac.ru\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n" }, { "commit": "b4b510290b056b86611757ce1175a230f1080f53", "tree": "7bd1d45855ac7457be6d50338c60751f19e436d9", "parents": [ "e9dc86534051b78e41e5b746cccc291b57a3a311" ], "author": { "name": "Eric W. Biederman", "email": "ebiederm@xmission.com", "time": "Wed Sep 12 13:05:38 2007 +0200" }, "committer": { "name": "David S. Miller", "email": "davem@sunset.davemloft.net", "time": "Wed Oct 10 16:49:09 2007 -0700" }, "message": "[NET]: Support multiple network namespaces with netlink\n\nEach netlink socket will live in exactly one network namespace,\nthis includes the controlling kernel sockets.\n\nThis patch updates all of the existing netlink protocols\nto only support the initial network namespace. Request\nby clients in other namespaces will get -ECONREFUSED.\nAs they would if the kernel did not have the support for\nthat netlink protocol compiled in.\n\nAs each netlink protocol is updated to be multiple network\nnamespace safe it can register multiple kernel sockets\nto acquire a presence in the rest of the network namespaces.\n\nThe implementation in af_netlink is a simple filter implementation\nat hash table insertion and hash table look up time.\n\nSigned-off-by: Eric W. Biederman \u003cebiederm@xmission.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n" }, { "commit": "af65bdfce98d7965fbe93a48b8128444a2eea024", "tree": "e6ac5ff82a0d5067213135cdf049b912b02e824d", "parents": [ "b076deb8498e26c9aa2f44046fe5e9936ae2fb5a" ], "author": { "name": "Patrick McHardy", "email": "kaber@trash.net", "time": "Fri Apr 20 14:14:21 2007 -0700" }, "committer": { "name": "David S. Miller", "email": "davem@sunset.davemloft.net", "time": "Wed Apr 25 22:29:03 2007 -0700" }, "message": "[NETLINK]: Switch cb_lock spinlock to mutex and allow to override it\n\nSwitch cb_lock to mutex and allow netlink kernel users to override it\nwith a subsystem specific mutex for consistent locking in dump callbacks.\nAll netlink_dump_start users have been audited not to rely on any\nside-effects of the previously used spinlock.\n\nSigned-off-by: Patrick McHardy \u003ckaber@trash.net\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n" }, { "commit": "b529ccf2799c14346d1518e9bdf1f88f03643e99", "tree": "f899a5a5d66d2ca21724c1871ee3afeda6c4a670", "parents": [ "965ffea43d4ebe8cd7b9fee78d651268dd7d23c5" ], "author": { "name": "Arnaldo Carvalho de Melo", "email": "acme@redhat.com", "time": "Wed Apr 25 19:08:35 2007 -0700" }, "committer": { "name": "David S. Miller", "email": "davem@sunset.davemloft.net", "time": "Wed Apr 25 22:26:34 2007 -0700" }, "message": "[NETLINK]: Introduce nlmsg_hdr() helper\n\nFor the common \"(struct nlmsghdr *)skb-\u003edata\" sequence, so that we reduce the\nnumber of direct accesses to skb-\u003edata and for consistency with all the other\ncast skb member helpers.\n\nSigned-off-by: Arnaldo Carvalho de Melo \u003cacme@redhat.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n" }, { "commit": "dddfa461fc8951f9b5f951c13565b6cac678635a", "tree": "eaf51d6825bd97087b9c700f7010ed08e3f83047", "parents": [ "88b4a07e6610f4c93b08b0bb103318218db1e9f6" ], "author": { "name": "Michael Halcrow", "email": "mhalcrow@us.ibm.com", "time": "Mon Feb 12 00:53:44 2007 -0800" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Mon Feb 12 09:48:36 2007 -0800" }, "message": "[PATCH] eCryptfs: Public key; packet management\n\nPublic key support code. This reads and writes packets in the header that\ncontain public key encrypted file keys. It calls the messaging code in the\nprevious patch to send and receive encryption and decryption request\npackets from the userspace daemon.\n\n[akpm@osdl.org: cleab fix]\nSigned-off-by: Michael Halcrow \u003cmhalcrow@us.ibm.com\u003e\nCc: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "88b4a07e6610f4c93b08b0bb103318218db1e9f6", "tree": "32e2f2650bd4841ba6b2fafc724c2806219351b4", "parents": [ "b5d5dfbd59577aed72263f22e28d3eaf98e1c6e5" ], "author": { "name": "Michael Halcrow", "email": "mhalcrow@us.ibm.com", "time": "Mon Feb 12 00:53:43 2007 -0800" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Mon Feb 12 09:48:36 2007 -0800" }, "message": "[PATCH] eCryptfs: Public key transport mechanism\n\nThis is the transport code for public key functionality in eCryptfs. It\nmanages encryption/decryption request queues with a transport mechanism.\nCurrently, netlink is the only implemented transport.\n\nEach inode has a unique File Encryption Key (FEK). Under passphrase, a File\nEncryption Key Encryption Key (FEKEK) is generated from a salt/passphrase\ncombo on mount. This FEKEK encrypts each FEK and writes it into the header of\neach file using the packet format specified in RFC 2440. This is all\nsymmetric key encryption, so it can all be done via the kernel crypto API.\n\nThese new patches introduce public key encryption of the FEK. There is no\nasymmetric key encryption support in the kernel crypto API, so eCryptfs pushes\nthe FEK encryption and decryption out to a userspace daemon. After\nconsidering our requirements and determining the complexity of using various\ntransport mechanisms, we settled on netlink for this communication.\n\neCryptfs stores authentication tokens into the kernel keyring. These tokens\ncorrelate with individual keys. For passphrase mode of operation, the\nauthentication token contains the symmetric FEKEK. For public key, the\nauthentication token contains a PKI type and an opaque data blob managed by\nindividual PKI modules in userspace.\n\nEach user who opens a file under an eCryptfs partition mounted in public key\nmode must be running a daemon. That daemon has the user\u0027s credentials and has\naccess to all of the keys to which the user should have access. The daemon,\nwhen started, initializes the pluggable PKI modules available on the system\nand registers itself with the eCryptfs kernel module. Userspace utilities\nregister public key authentication tokens into the user session keyring.\nThese authentication tokens correlate key signatures with PKI modules and PKI\nblobs. The PKI blobs contain PKI-specific information necessary for the PKI\nmodule to carry out asymmetric key encryption and decryption.\n\nWhen the eCryptfs module parses the header of an existing file and finds a Tag\n1 (Public Key) packet (see RFC 2440), it reads in the public key identifier\n(signature). The asymmetrically encrypted FEK is in the Tag 1 packet;\neCryptfs puts together a decrypt request packet containing the signature and\nthe encrypted FEK, then it passes it to the daemon registered for the\ncurrent-\u003eeuid via a netlink unicast to the PID of the daemon, which was\nregistered at the time the daemon was started by the user.\n\nThe daemon actually just makes calls to libecryptfs, which implements request\npacket parsing and manages PKI modules. libecryptfs grabs the public key\nauthentication token for the given signature from the user session keyring.\nThis auth tok tells libecryptfs which PKI module should receive the request.\nlibecryptfs then makes a decrypt() call to the PKI module, and it passes along\nthe PKI block from the auth tok. The PKI uses the blob to figure out how it\nshould decrypt the data passed to it; it performs the decryption and passes\nthe decrypted data back to libecryptfs. libecryptfs then puts together a\nreply packet with the decrypted FEK and passes that back to the eCryptfs\nmodule.\n\nThe eCryptfs module manages these request callouts to userspace code via\nmessage context structs. The module maintains an array of message context\nstructs and places the elements of the array on two lists: a free and an\nallocated list. When eCryptfs wants to make a request, it moves a msg ctx\nfrom the free list to the allocated list, sets its state to pending, and fires\noff the message to the user\u0027s registered daemon.\n\nWhen eCryptfs receives a netlink message (via the callback), it correlates the\nmsg ctx struct in the alloc list with the data in the message itself. The\nmsg-\u003eindex contains the offset of the array of msg ctx structs. It verifies\nthat the registered daemon PID is the same as the PID of the process that sent\nthe message. It also validates a sequence number between the received packet\nand the msg ctx. Then, it copies the contents of the message (the reply\npacket) into the msg ctx struct, sets the state in the msg ctx to done, and\nwakes up the process that was sleeping while waiting for the reply.\n\nThe sleeping process was whatever was performing the sys_open(). This process\noriginally called ecryptfs_send_message(); it is now in\necryptfs_wait_for_response(). When it wakes up and sees that the msg ctx\nstate was set to done, it returns a pointer to the message contents (the reply\npacket) and returns. If all went well, this packet contains the decrypted\nFEK, which is then copied into the crypt_stat struct, and life continues as\nnormal.\n\nThe case for creation of a new file is very similar, only instead of a decrypt\nrequest, eCryptfs sends out an encrypt request.\n\n\u003e - We have a great clod of key mangement code in-kernel. Why is that\n\u003e not suitable (or growable) for public key management?\n\neCryptfs uses Howells\u0027 keyring to store persistent key data and PKI state\ninformation. It defers public key cryptographic transformations to userspace\ncode. The userspace data manipulation request really is orthogonal to key\nmanagement in and of itself. What eCryptfs basically needs is a secure way to\ncommunicate with a particular daemon for a particular task doing a syscall,\nbased on the UID. Nothing running under another UID should be able to access\nthat channel of communication.\n\n\u003e - Is it appropriate that new infrastructure for public key\n\u003e management be private to a particular fs?\n\nThe messaging.c file contains a lot of code that, perhaps, could be extracted\ninto a separate kernel service. In essence, this would be a sort of\nrequest/reply mechanism that would involve a userspace daemon. I am not aware\nof anything that does quite what eCryptfs does, so I was not aware of any\nexisting tools to do just what we wanted.\n\n\u003e What happens if one of these daemons exits without sending a quit\n\u003e message?\n\nThere is a stale uid\u003c-\u003epid association in the hash table for that user. When\nthe user registers a new daemon, eCryptfs cleans up the old association and\ngenerates a new one. See ecryptfs_process_helo().\n\n\u003e - _why_ does it use netlink?\n\nNetlink provides the transport mechanism that would minimize the complexity of\nthe implementation, given that we can have multiple daemons (one per user). I\nexplored the possibility of using relayfs, but that would involve having to\nintroduce control channels and a protocol for creating and tearing down\nchannels for the daemons. We do not have to worry about any of that with\nnetlink.\n\nSigned-off-by: Michael Halcrow \u003cmhalcrow@us.ibm.com\u003e\nCc: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" } ] }