selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Casey Schaufler <casey@schaufler-ca.com>,
	Oleg Nesterov <oleg@redhat.com>, Paul Moore <paul@paul-moore.com>
Cc: "chengjian (D)" <cj.chengjian@huawei.com>,
	Kees Cook <keescook@chromium.org>, NeilBrown <neilb@suse.com>,
	Anna Schumaker <Anna.Schumaker@netapp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"Xiexiuqi (Xie XiuQi)" <xiexiuqi@huawei.com>,
	Li Bin <huawei.libin@huawei.com>, Jason Yan <yanaijie@huawei.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Linux Security Module list 
	<linux-security-module@vger.kernel.org>,
	SELinux <selinux@vger.kernel.org>,
	Yang Yingliang <yangyingliang@huawei.com>
Subject: Re: kernel BUG at kernel/cred.c:434!
Date: Thu, 18 Apr 2019 09:39:40 -0400	[thread overview]
Message-ID: <4493cc24-4023-028c-1007-0f61f63a5bda@tycho.nsa.gov> (raw)
In-Reply-To: <939a45a6-fc1b-0ac3-759b-0e7c3ce3d670@schaufler-ca.com>

On 4/17/19 12:42 PM, Casey Schaufler wrote:
> On 4/17/2019 9:27 AM, Oleg Nesterov wrote:
>> On 04/17, Paul Moore wrote:
>>> On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov <oleg@redhat.com> wrote:
>>>> On 04/17, Paul Moore wrote:
>>>>> I'm tempted to simply return an error in selinux_setprocattr() if
>>>>> the task's credentials are not the same as its real_cred;
>>>> What about other modules? I have no idea what smack_setprocattr() is,
>>>> but it too does prepare_creds/commit creds.
>>>>
>>>> it seems that the simplest workaround should simply add the additional
>>>> cred == real_cred into proc_pid_attr_write().
>>> Yes, that is simple, but I worry about what other LSMs might want to
>>> do.  While I believe failing if the effective creds are not the same
>>> as the real_creds is okay for SELinux (possibly Smack too), I worry
>>> about what other LSMs may want to do.  After all,
>>> proc_pid_attr_write() doesn't change the the creds itself, that is
>>> something the specific LSMs do.
>> Yes, but if proc_pid_attr_write() is called with cred != real_cred then
>> something is already wrong?
>>
>> In fact, I think that something is already wrong if it is not called by
>> user-space directly. Too late to ask, but why is this /proc/self/attr/
>> magic not implemented via syscall(s) ?
> 
> Shell scripts, for one thing. It's a straightforward and appropriate
> use of the /proc interface. System calls would require additional change
> to existing programs, whereas using the /proc interface allows a good
> deal to be done in the containing scripts.

It is fairly awkward/fragile to use these interfaces from shell scripts 
due to limitations of the interface (e.g. no partial writes, thereby 
breaking if the shell splits up the data into multiple write() calls) 
and due to the fact that most of the attributes (except for current) are 
typically reset/cleared upon exec to prevent undue caller/callee 
influence.  It works well enough for echo -n "somelabel" > 
/proc/self/attr/current but not much else, and even that doesn't work 
without the -n due to multiple write() calls.

Just for the record, this functionality was originally implemented via 
separate system calls at least for SELinux (in its original kernel 
patch), then multiplexed through the single LSM security system call 
upon porting to LSM (before merging to mainline), but viro and others 
strongly favored using /proc as the interface for getting/setting any 
new process attributes.  Understandable, but it does impose some 
limitations, including a dependency on having a writable proc mount in 
the namespace of any process that needs to set any of these attributes,

  reply	other threads:[~2019-04-18 13:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6e4428ca-3da1-a033-08f7-a51e57503989@huawei.com>
2019-04-12 15:28 ` kernel BUG at kernel/cred.c:434! Casey Schaufler
2019-04-15 13:43   ` Oleg Nesterov
2019-04-15 14:48     ` Paul Moore
2019-04-15 15:05       ` Oleg Nesterov
2019-04-15 16:20         ` Paul Moore
2019-04-16  3:40           ` Kees Cook
2019-04-16 14:46             ` chengjian (D)
2019-04-17 14:30               ` Paul Moore
2019-04-17 14:57                 ` Oleg Nesterov
2019-04-17 15:39                   ` Casey Schaufler
2019-04-17 15:40                   ` Paul Moore
2019-04-17 16:27                     ` Oleg Nesterov
2019-04-17 16:42                       ` Casey Schaufler
2019-04-18 13:39                         ` Stephen Smalley [this message]
2019-04-17 23:39                       ` Paul Moore
2019-04-18  0:17                         ` John Johansen
2019-04-18  0:24                         ` Casey Schaufler
2019-04-18  2:49                           ` Yang Yingliang
2019-04-19  2:04                             ` Paul Moore
2019-04-19  2:34                               ` Yang Yingliang
2019-04-19 13:24                                 ` Paul Moore
2019-04-19 14:34                                   ` Yang Yingliang
2019-04-19 16:13                                     ` Paul Moore
2019-04-20  7:38                                       ` Yang Yingliang
2019-04-22 19:48                                         ` Paul Moore
2019-04-23  4:08                                           ` Yang Yingliang
2019-04-23 20:18                                             ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4493cc24-4023-028c-1007-0f61f63a5bda@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=Anna.Schumaker@netapp.com \
    --cc=casey@schaufler-ca.com \
    --cc=cj.chengjian@huawei.com \
    --cc=huawei.libin@huawei.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=neilb@suse.com \
    --cc=oleg@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=peterz@infradead.org \
    --cc=selinux@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xiexiuqi@huawei.com \
    --cc=yanaijie@huawei.com \
    --cc=yangyingliang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).