[PATCH v2 3/9] procfs: Document the proposed solution to protect procfs entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Note the proposed solution to protect sensitive procfs entries as
code comment.

Cc: Kees Cook <keescook@xxxxxxxxxxxx>
Suggested-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Signed-off-by: Djalal Harouni <tixxdz@xxxxxxxxxx>
---
 fs/proc/base.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index c29eeae..8d21316 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -102,6 +102,17 @@
  *
  *	The classic example of a problem is opening file descriptors
  *	in /proc for a task before it execs a suid executable.
+ *
+ * Solution for sensitive files:
+ *	At each system call: open(),read(),write()... Perform the
+ *	ptrace_may_access() check.
+ *
+ *	After open() and during each system call: read(),write()...
+ *	If the cred of current have changed then perform the
+ *	proc_allow_access() check after the ptrace_may_access() one.
+ *
+ *	This way we can determine if current has gained more privileges
+ *	by execs a suid executable.
  */
 
 struct pid_entry {
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux