public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Muli Ben-Yehuda <mulix@mulix.org>
To: Maciej Zenczykowski <maze@cela.pl>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Syscall security
Date: Fri, 26 Sep 2003 18:16:42 +0300	[thread overview]
Message-ID: <20030926151642.GL729@actcom.co.il> (raw)
In-Reply-To: <Pine.LNX.4.44.0309261553180.6080-100000@gaia.cela.pl>

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On Fri, Sep 26, 2003 at 04:05:50PM +0200, Maciej Zenczykowski wrote:

> I'm wondering if there is any way to provide per process bitmasks of 
> available/illegal syscalls.  Obviously this should most likely be 
> inherited through exec/fork.

syscalltrack can do it, per executable / user / syscall parameters /
whatever, but it's per syscall. Writing a perl script or C program to
iterate over the supplied syscall list and write the allow/deny rules
is pretty simple. Also, syscalltrack is meant for debugging, not
security, so if you want something that's 100% tight you'd better go
with one of the Linux security modules based on the LSM framework. 

> For example specyfying that pid N should return -ENOSYS on all syscalls 
> except read/write/exit.

Yeah, syscalltrack can do that ;-) 

> The reason I'm asking is because I want to run totally untrusted 
> statically linked binary code (automatically compiled from user 
> submitted untrusted sources) which only needs read/write access to stdio 
> which means it only requires syscalls read/write/exit + a few more for
> memory alloc/free (like brk) + a few more generated before main is called 
> (execve and uname I believe).

Since it's a known binary, if you can handle the increased run time,
strace is your best shot. syscalltrack and other kernel based
solutions are best when you need something that is "system wide". 

> Basically my question is: has this been done before (if so where/when?), 
> what would be considered 'the right' way to do this, would this be a 
> feature to include in the main kernel source?

Previous discussion seemed to conclude that features like these are
"not interesting enough to the majority of users". Maybe it's time to
revise those discussions (c.f. the inclusion of SELinux, for
example). 
-- 
Muli Ben-Yehuda
http://www.mulix.org


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2003-09-26 15:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-26 14:05 Syscall security Maciej Zenczykowski
2003-09-26 14:10 ` Ingo Molnar
2003-09-26 14:16   ` Maciej Zenczykowski
2003-09-26 14:19     ` Ingo Molnar
2003-09-26 14:21     ` Ruth Ivimey-Cook
2003-09-26 16:14       ` Maciej Zenczykowski
2003-09-26 15:01     ` Davide Libenzi
2003-09-26 16:18       ` Maciej Zenczykowski
2003-09-28 11:38     ` Kenneth Johansson
2003-09-26 15:16 ` Muli Ben-Yehuda [this message]
2003-09-26 16:25   ` Maciej Zenczykowski
2003-09-26 15:18 ` Joe McClain
2003-09-26 16:10 ` Chris Wright

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=20030926151642.GL729@actcom.co.il \
    --to=mulix@mulix.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maze@cela.pl \
    /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