linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacques Gelinas <jack@solucorp.qc.ca>
To: linux-kernel@vger.kernel.org
Subject: re: User-manageable sub-ids proposals
Date: Thu, 13 Dec 2001 11:02:15 -0500	[thread overview]
Message-ID: <20011213110215.bfcc4bfa0b14@remtk.solucorp.qc.ca> (raw)

On Thu, 13 Dec 2001 11:36:16 -0500, Romano Giannetti wrote
> Good morning to everyone.
>
> I was thinking about the idea of sub-ids to enable users to run "untrusted"
> binary or "dangerous" one without risk for their files/privacy.

I have another solution, which is almost completed. I am combining
two project. One is the vserver project (see the url in my signature) and the
other is the AclFS component of the virtualfs project
(http://www.solucorp.qc.ca/virtualfs).

Using the chcontext utility from the vserver project, you can isolate a process
from the rest of the system, including the other user processes

For example, as a normal user, you can do

	xterm &
	/usr/sbin/chcontext /bin/sh
	ps ax
	killall xterm

and you only see your new shell, the ps command and init. The killall fails
finding no xterm to kill.

Another part of the vserver project is the capability ceiling, which is a way to
turn off some capabilities for a process and its children, even setuid child.

I was thinking about introducing a new capability CAP_OPEN. This capability
would prevent any open system call from succeeding. Wow. Now that's secure :-)

The acslfs daemon works using a unix domain socket. Using a preload object
the client does various system call request to aclfsd, including open, socket
and so on. If aclfsd grant the access, it opens the file and pass back the
file handle using the socket. So the client does not need to open the file
itself.

So the CAP_OPEN is there to force the client to use aclfsd. Even if using aclfsd
is transparent to normal clients, some client might do a direct call to the OS.
All those calls would fail.

Not also that aclfsd does not need any privilege. A normal user may start
it with its own configurations (access privileges).

Ultimatly, one goal of this would be to run your favorite browser in a security
box and allow fine grain access to your own file. Then one could do the so
cool thing windows user do all the time: They visit a site, select a plugin
and run it. Unlike windows, you would not get all the virus though :-)

Anyway, the vserver and virtual projects are used for different purpose today
but could be combined to achieve this kind of result.

---------------------------------------------------------
Jacques Gelinas <jack@solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc

             reply	other threads:[~2001-12-13 18:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-13 16:02 Jacques Gelinas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-12-05  3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08  4:58   ` Nathan Scott
2001-12-08 20:17     ` Hans Reiser
2001-12-11  2:42       ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 19:23         ` Anton Altaparmakov
2001-12-11 21:21           ` Hans Reiser
2001-12-13  1:43             ` Andrew Pimlott
2001-12-13  9:23               ` Hans Reiser
2001-12-13 10:36                 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37                   ` Ragnar Kjørstad
2001-12-13 16:06                     ` Romano Giannetti
2001-12-13 18:58                       ` Ragnar Kjørstad
2001-12-18  0:17                     ` Pavel Machek
2001-12-13 23:24                   ` David Wagner
2001-12-21 21:28                   ` Andreas Ferber

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=20011213110215.bfcc4bfa0b14@remtk.solucorp.qc.ca \
    --to=jack@solucorp.qc.ca \
    --cc=linux-kernel@vger.kernel.org \
    /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).