From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753515AbbIHWmr (ORCPT ); Tue, 8 Sep 2015 18:42:47 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:44403 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752172AbbIHWmo (ORCPT ); Tue, 8 Sep 2015 18:42:44 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: , "Serge E. Hallyn" Date: Tue, 08 Sep 2015 17:35:38 -0500 Message-ID: <874mj4o7yd.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+FsacLOv9ZsTHPL18MYHNT947xkv2bfc8= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4977] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 148 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.8 (3.3%), b_tie_ro: 3.4 (2.3%), parse: 1.05 (0.7%), extract_message_metadata: 4.0 (2.7%), get_uri_detail_list: 1.60 (1.1%), tests_pri_-1000: 3.0 (2.0%), tests_pri_-950: 0.95 (0.6%), tests_pri_-900: 0.77 (0.5%), tests_pri_-400: 14 (9.7%), check_bayes: 14 (9.2%), b_tokenize: 3.3 (2.2%), b_tok_get_all: 4.4 (3.0%), b_comp_prob: 1.34 (0.9%), b_tok_touch_all: 2.3 (1.6%), b_finish: 0.68 (0.5%), tests_pri_0: 101 (67.9%), tests_pri_500: 6 (4.0%), rewrite_mail: 0.00 (0.0%) Subject: RFC: fsyscall X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I was thinking a bit about the problem of allowing another process to perform a subset of what your process can perform, and it occured to me there might be something conceptually simple we can do. Have a system call fsyscall that takes a file descriptor the system call number and the parameters to that system call as arguments. AKA long fsyscall(int fd, long number, ...); AKA syscall with a file desciptor argument. The fd would hold a struct cred, and a filter that limits what system calls and which parameters may be passed. The implementation of fsyscall would be something like: old = override_creds(f->f_cred); /* Perform filtered syscallf */ revert_creds(old); Then we have another system call call it fsyscall_create(...) that takes a bpf filter and returns a file descriptor, that can be used with fsyscall. I'm not certain that bpf is the best way to create such a filter but it seems plausible, and we already have the infrastructure in place, so if nothing else there would be synergy in syscall filtering. My two concerns with bpf are (a) it seems a little complex for the simplest use cases. (b) I think there cases like inspecting the data passed into write, or send, or the structure passed into ioctl that it doesn't handle well yet. Andy does a fsyscall system call sound like something that would be not be too bad to implement? (You have just been through all of the x86 system call paths recently). Eric