SELinux: do not check open on dir path walk

Things like link_path_walk check for MAY_EXEC on directories as it walks path names. The open perms checking was actually checking open on these as well. This patch excludes checking open when the only requested permission on the dir was MAY_EXEC. open and opendir both still require open perms.

Signed-off-by Eric Paris <[email protected]>

---

 security/selinux/hooks.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

security/selinux/hooks.c +5 -4

index 3e3fde7..188284f 100644
@@ -1707,11 +1707,12 @@ static inline u32 open_file_mask_to_av(int mode, int mask)
 			av |= BLK_FILE__OPEN;
 		else if (S_ISFIFO(mode))
 			av |= FIFO_FILE__OPEN;
-		else if (S_ISDIR(mode))
-			av |= DIR__OPEN;
-		else
+		else if (S_ISDIR(mode)) {
+			if (mask != MAY_EXEC)
+				av |= DIR__OPEN;
+		} else
 			printk(KERN_ERR "SELinux: WARNING: inside %s with "
-				"unknown mode:%x\n", __func__, mode);
+				"unknown mode:%o mask:%x\n", __func__, mode, mask);
 	}
 	return av;
 }

Quoted 4 lines · Eric Paris

Things like link_path_walk check for MAY_EXEC on directories as it walks path names. The open perms checking was actually checking open on these as well. This patch excludes checking open when the only requested permission on the dir was MAY_EXEC. open and opendir both still require open perms.

Would these issues (both directory search and unix socket) have been avoided if you had put the open check in the dentry_open hook instead of the inode_permission hook?

Quoted 6 lines · Stephen Smalley

Quoted 4 lines · Eric Paris

Things like link_path_walk check for MAY_EXEC on directories as it walks path names. The open perms checking was actually checking open on these as well. This patch excludes checking open when the only requested permission on the dir was MAY_EXEC. open and opendir both still require open perms.

Quoted 3 lines

Would these issues (both directory search and unix socket) have been avoided if you had put the open check in the dentry_open hook instead of the inode_permission hook?

Both are the result of explicit calls to inode_permission so yes, they would have been avoided.