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
| ||
|
Date: Fri, 07 Sep 2018 11:47:39 +0200 From: Lukasz Pawelczyk <l.pawelczyk@...sung.com> To: Casey Schaufler <casey@...aufler-ca.com> Cc: linux-security-module <linux-security-module@...r.kernel.org>, kernel list <linux-kernel@...r.kernel.org> Subject: Re: Fwd: Smack: wrong-looking capable() check in smk_ptrace_rule_check() Hi, On Thu, 2018-09-06 at 11:53 -0700, Casey Schaufler wrote: > Lukasz, does this analysis seem correct to you? This is code you > wrote in 2014. It seems correct. Moreover I've sent a patch that fixes this bug long time ago with the namespace series. https://lists.linux-foundation.org/pipermail/containers/2015-October/036318.html Not sure this is the latest version. The latest I ever wrote can be found here: https://github.com/Havner/smack-namespace/commit/52d6e4be2db51e9aca53e0e112a7ff9625000994 Without namespaces, parts of this patch are probably irrelevant, but it does fix this bug and one or two similar elsewhere. Best regards, Lukasz > > -------- Forwarded Message -------- > Subject: Smack: wrong-looking capable() check in > smk_ptrace_rule_check() > Date: Thu, 6 Sep 2018 20:22:35 +0200 > From: Jann Horn <jannh@...gle.com> > To: Casey Schaufler <casey@...aufler-ca.com> > CC: linux-security-module <linux-security-module@...r.kernel.org>, > kernel list <linux-kernel@...r.kernel.org> > > Hi! > > I noticed the following check in smk_ptrace_rule_check(): > > if (tracer_known->smk_known == tracee_known- > >smk_known) > rc = 0; > else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN) > rc = -EACCES; > else if (capable(CAP_SYS_PTRACE)) > rc = 0; > else > rc = -EACCES; > > Note that smk_ptrace_rule_check() can be called from not just > smack_ptrace_access_check() and smack_ptrace_traceme(), but also > smack_bprm_set_creds(). AFAICS this means that if a task executes > with > a smack privilege transition and smack_ptrace_rule is > SMACK_PTRACE_EXACT, whether the execution is permitted depends on > whether _the debugged task_ has CAP_SYS_PTRACE (and not on whether > the > debugger has that capability). > This seems like it's probably unintentional? > > -- Lukasz Pawelczyk Samsung R&D Institute Poland Samsung Electronics
Powered by blists - more mailing lists