linux-kernel - file caps: permit unsafe signaling when CONFIG_FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061124161626.GA22462@sergelap.austin.ibm.com>
Date:	Fri, 24 Nov 2006 10:16:26 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Chris Friedhoff <chris@...edhoff.org>,
	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Stephen Smalley <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Chris Wright <chrisw@...s-sol.org>,
	KaiGai Kohei <kaigai@...gai.gr.jp>,
	Alexey Dobriyan <adobriyan@...il.com>
Subject: file caps: permit unsafe signaling when CONFIG_FS_CAPS=n

Ok, the following patch restores the CONFIG_FS_CAPS=n signaling
behavior, but I'm having a config problem.  When
CONFIG_SECURITY_CAPABILITIES=n, and I toggle
CONFIG_SECURITY_FS_CAPABILITIES between y and n, security/commoncap.o
does not recompile.  However since capabilities are now the default
security module, commoncap.o is in fact included in the kernel build,
and therefore should be recompiled.

Looking into why, but maybe someone knows offhand what would be going
wrong?

thanks,
-serge

From: Serge E. Hallyn <serue@...ibm.com>
Subject: [PATCH 1/1] file caps: permit unsafe signaling when CONFIG_FS_CAPS=n

In legacy behavior, when a user starts a setuid program, that user
can send signals to the running program.  The file capabilities
patch prevents that not only when file capabilities are enabled,
but in all cases where capabilities are used.

For instance, when starting the X server, which is setuid root, it
is expected that the user who started it be able to kill it.

Existing behavior should not be changed.  This patch should reenable
signaling setuid processes started by the signaling user.

Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
---
 security/commoncap.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 0e89f1b..04b277f 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -389,6 +389,7 @@ int cap_task_post_setuid (uid_t old_ruid
 	return 0;
 }

+#ifdef CONFIG_SECURITY_FS_CAPABILITIES
 /*
  * Rationale: code calling task_setscheduler, task_setioprio, and
  * task_setnice, assumes that
@@ -444,6 +445,26 @@ int cap_task_kill(struct task_struct *p,

 	return -EPERM;
 }
+#else
+int cap_task_setscheduler (struct task_struct *p, int policy,
+			   struct sched_param *lp)
+{
+	return 0;
+}
+int cap_task_setioprio (struct task_struct *p, int ioprio)
+{
+	return 0;
+}
+int cap_task_setnice (struct task_struct *p, int nice)
+{
+	return 0;
+}
+int cap_task_kill(struct task_struct *p, struct siginfo *info,
+				int sig, u32 secid)
+{
+	return 0;
+}
+#endif

 void cap_task_reparent_to_init (struct task_struct *p)
 {
-- 
1.4.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/