Date: Mon, 1 Aug 2016 08:38:45 +0000 From: "Reshetova, Elena" <elena.reshetova@...el.com> To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> CC: "linux-security-module@...r.kernel.org" <linux-security-module@...r.kernel.org>, "keescook@...omium.org" <keescook@...omium.org>, "spender@...ecurity.net" <spender@...ecurity.net>, "jmorris@...ei.org" <jmorris@...ei.org>, "Schaufler, Casey" <casey.schaufler@...el.com>, "Leibowitz, Michael" <michael.leibowitz@...el.com>, "Roberts, William C" <william.c.roberts@...el.com> Subject: RE: [RFC] [PATCH 1/5] path_fchdir and path_fhandle LSM hooks >On Sun, Jul 31, 2016 at 06:28:08PM +0000, Reshetova, Elena wrote: > On Sun, Jul 31, 2016 at 10:55:04AM +0000, Reshetova, Elena wrote: [...] > >Alternatively, you could forbid double-chroots and use the LSM hooks > >for > file descriptor passing via unix domain sockets and binder to check > incoming file descriptors. > > This would not prevent guessing the file descriptor unfortunately. >That doesn't make sense to me. Can you elaborate on that, please? >How would you "guess" a file descriptor? Are you talking about file descriptors opened before chroot() that have been leaked accidentally? Yes, these ones. Also I guess in general security-wise it is better approach to have a check in a place where descriptor will be attempted to use/resolved vs. trying to make sure you caught all cases where/how process might obtain some. Various IPC, leaked descriptors, some other potential surprises... But I think in this case it might be worth trying to do what you suggest since I don't see good alternatives either. >In that case, you could just do on chroot() what SELinux does on a domain transition and replace all dangerous open file descriptors with /dev/null. I guess this could work, if I can correctly close the ones that are outside of the chroot. I will check how SELinux does it. Thank you for the tip! >Or are you concerned about shared file descriptor tables (which really shouldn't happen accidentally, You mean CLONE_FILES on clone()? If yes, then I am less concerned of this since it really not common as far as I understood for legitimate processes/daemons to be started this way. However, if this case needs to be addressed, it is trickier, you cannot just substitute these ones with /dev/null without breaking the parent also and you would need to check them all, not just opened ones. > at least when you keep in mind that for this to be an issue, the fs_struct would have to not be shared)? What do you mean by the last part? Not sure I understand here... Download attachment "smime.p7s" of type "application/pkcs7-signature" (7586 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.