linux-kernel - Re: [PATCH] Smack: fix domain transfer issues

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: <alpine.DEB.2.02.1109291109070.3006@jsakkine-mobl>
Date:	Thu, 29 Sep 2011 11:26:57 +0300 (EEST)
From:	Jarkko Sakkinen <jarkko.sakkinen@...el.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
cc:	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Smack: fix domain transfer issues

On Wed, 28 Sep 2011, Stephen Smalley wrote:
> Did I miss something or did you find a rationale for using bprm->unsafe
> in this manner?  It isn't private to your security module yet you are
> claiming a bit for your own private use without reserving it in any way
> globally (consider implications for any future stacking), and setting
> new bits in it will have side effects on the capabilities logic.  I
> already mentioned this on your first patch and you seemed to acknowledge
> it then.  Pass it via bprm->cred->security if you need to pass it as a
> flag, or re-test the condition in the secureexec hook otherwise.

You got your point. I'll add smk_flags field to
the struct task_smack (our task security blob).

> Why not just:
> 	if (bprm->unsafe)
> 		return -EPERM;
> if you aren't going to distinguish them via permission checks or
> anything?

I guess my purpose was to leave those visible because
plan is to add permission checks at least for the
ptrace case in the future. Now that I think of it,
it does not justify their existence in the code.
I'll revise this.

Even in the current form, there should be check that
you described to protect this code against situation
where new LSM_UNSAFE flag is added and support has not
yet been implemented to Smack.

>
> I take it you've decided you don't need any of the other checks or
> sanitization applied by SELinux?

MNT_NOSUID should be checked. Also, I'll plan to
implement permission check for ptrace but in the
scope of this patch.

Thanks for informative reply!

/Jarkko
--
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/