lkml.org 
[lkml]   [2000]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: compartment || the other way of compartment
Hi,


When you call a program compartment and present it as a program to build secure compartments for running untrusted/insecure programs, then it should build secure compartments for running untrusted/insecure programs. When you talk about secure compartments you chould think of 2 ways to make it secure. The first
way is to just put the program at some other uid/gid and set some chroot.

The other way is to set limits for a program without touching the uid/gid. If you would like to run a ftpserver for users it should have the capability
to change uid/gid to the user that logs in. You could create just another CAP for that like CAP_CHUID and CAP_CHGID but i doubt if that would make to run the program still in a secure compartment.

RooT66 (a group of coders/securityfreaks) is coding a kernel patch which generally does the following:

We expand struct task_struct with a pointer to an array of strings (array of chars). This array of strings contains rules for the opening of files. In that array of strings you can set (with basic regular expressions) what files are allowed to be opened for reading/writing/special and what files are allowed to
be executed by the proccess.

We edited the SYS_execve and the SYS_open calls to make them first take a look in the array of strings of the process that wants to open/execute to see
if it is allowed.

Those rules should be put in configfiles, perhaps we use just one config file placed on the filesystem like /etc/auditfile.conf or perhaps we put that behind the 0x00 of binarys on the filesystem. Still thinking bout that.

When a process is made ready for execution the array of strings is filled with the array of strings of the parent of that process to be run and the array of strings of the config file valid for this new process is added to this array of strings.



The reason we do this is because linux memory is put in protected mode. Therefor no interrupts are available to running processes and everything is handled by sys_calls. When we put audits on those sys_calls you create a compartment of that process without touching the uid/gid.

Now when an evil hacker exploits my bind making that process to do evil stuff he could read all my ^/var/named/.*\.zone$ files and append stuff to my logfile. He cant execute anything and with some nice set ulimits the bind process is pretty safe.


I would like to get some response about this technique.


Frank van Vliet
RooT66 - http://root66.org
karin@root66.org


From bugtraq:

On Mon, Jan 03, 2000 at 08:34:20PM +0100, Marc Heuse wrote:
> Hi folks,
>
> I just wanted to announce, that a small but nice tool is available for
> testing. It's a program to build secure compartments for running
> untrsted/insecure programs, and has got the usual uid/gid setting and
> chrooting abilitity, but the nice thing is the easy access to linux per
> process capabilities.
>
> e.g. running an anon-ftp or webserver software on a priviliged port chrooted:
> "compartment --chroot /chroot/ftp --cap CAP_NET_BIND_SERVICE anon-ftpd"
>
> You can find v0.5 of the compartment utility at http://www.suse.de/~marc
>
>
> Syntax: compartment [options] /full/path/to/program
>
> Options:
> --chroot path chroot to path
> --user user change uid to this user
> --group group change gid to this group
> --init program execute this program/script before doing anything
> --cap capset set capset name. You can specify several capsets.
> --verbose be verbose
> --quiet do no logging (to syslog)
>
> I know the following capset names: CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH
> CAP_FOWNER CAP_FSETID CAP_FS_MASK CAP_KILL CAP_SETGID CAP_SETUID CAP_SETPCAP
> CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_ADMIN
> CAP_NET_RAW CAP_IPC_LOCK CAP_IPC_OWNER CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_CHROOT
> CAP_SYS_PTRACE CAP_SYS_PACCT CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_NICE
> CAP_SYS_RESOURCE CAP_SYS_TIME CAP_SYS_TTY_CONFIG
>
>
> Greets,
> Marc
> --
> Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg
> E@mail: marc@suse.de Function: Security Support & Auditing
> "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka"
> Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.031 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site