Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Aug 2016 08:38:45 +0000
From: "Reshetova, Elena" <>
To: ""
CC: ""
	<>, ""
	<>, "" <>,
	"" <>, "Schaufler, Casey"
	<>, "Leibowitz, Michael"
	<>, "Roberts, William C"
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.