File Share and Sandbox project

[David Walter]

I   am developing  a   thesis topic  using the   GNU/Hurd   OS as  the
implementation platform.

I'd be interested to  see  the comments that any   and all might  have
regarding these ideas.

So far, I have  come up with a first  draft proposal to use translator
composition as a mechanism to  build a secure environment, potentially
one that  is portable and, hopefully  one that provides some degree of
user anonymity  for  privacy. 

I. Overview

1. The  GNU/Hurd OS design can be  used for secure  and anonymous work
environments,  with a balance  of user control and system protections.
The following  items  are  the work  that I   intend  to  implement to
demonstrate these points:

        a. a  proof of concept  translator for user  configurable file
        sharing

        b. an authentication server using public key technology.

        c. a console client combined with the authentication server to
        encapsulate a user email process.

        d. demonstrate the  composition of these  to create  a virtual
        sandbox,  where the  file  space  and  the  user interface are
        confined by the Hurd authentication processes and translators.

2.   The GNU/Hurd  OS is a   _better_ mouse trap.   There are security
solutions which are cleaner to implement using it. Where by cleaner, I
mean that there is substantial motivation to code/utility reuse. 


3.  Verifiability: The GNU/Hurd   OS's  security can be verified  more
easily  than traditional monolithic  kernels  because  of  the  use of
translators and a micro kernels and the reduction of sharing of kernel
memory.

One of  the problems with  monolithic kernels and verifiability is that
the address  space of  the kernel includes  many   of the devices  and
shared data  structures used by the  kernel  to share information with
the drivers.

This leads  to potential side effects which  are difficult to find, as
unrelated sections of  the kernel can  affect / modify other unrelated
locations.

Loadable modules share these same problems.

GNU/Hurd has the potential to reduce these problems through separation
of  drivers from the  kernel  as well  as ability to  compartmentalize
functionality that traditionally would have been a kernel component.


II. User Configurable File Share Translator

While looking  at  the problem  of file  sharing  in user   space, the
administration problems have  been traditionally a  poison pill in the
ubiquitous adoption of file sharing in secure environments.

The work that an administrator has to do in a traditional *nix (POSIX)
environment   requires the maintenance  of  users  and groups, and the
granularity of  access control is limited to  the compositions of users
in  groups.   A user  belonging  to   a group has  access  privileges
equivalent to any other user in the group, unless the owner gives away
their  ownership,    or they begin  having  the   problem of end users
attempting  to define  a  complex  relationship  of interactions in  a
shared user space. 

Goal   one:   enable simple  user   configurable   file  sharing  with
granularity, in a user space implementation.

Example application: 'fileshare' translator.




When  Joe  wishes to  share  information with  Mary,  in a traditional
environment, he  may give world permissions so  that anyone has access
to the information, or he may give ownership of the file / information
to Mary,  or the administrator  must create a group  to which  Joe and
Mary belong.

In order   to  understand a  'hurdish'  implementation option  and the
associated security analysis  we would have to  consider  how the Hurd
processes information and how it handles authentication.

First the goals.  

1. We want to reduce the administration overhead

2. We want to empower the  end user to share  information they want to
share that they have access to, but  disable the acquisition of greater
privileges.

3. We want a flexible model for implementation.

Example goal:

Joe wants to  give  Mary  access  to the   following files in    these
respective locations:
   File                         Joe access rights/privileges
1. ~/reports/proj1              drwx------    1 joe       joe
2. ~/images/graphic.jpg         -rw-r--r--    1 joe       joe
3. ~/slides/slides.ps           -rw-r--r--    1 joe       joe

Joe  wants   to  allow  Mary to  have  read/write/execute   access  to
reports/proj1 read-only access to graphic.jpg and read/write access to
slides.ps .

   File                         joes access rights/privileges
1. ~/reports/proj1              drwxrwx---    1 joe       mary
2. ~/images/graphic.jpg         -rw-r-----    1 joe       mary
3. ~/slides/slides.ps           -rw-rw----    1 joe       mary

Further joe wants  to disallow other users to  be given access  to the
files by mary.

Now Joe can do the following: (assuming  we have written our fileshare
translator)

mkdir -p /home/share/joe/mary

settrans /home/share/joe/mary /hurd/fileshare --user-names=mary \
         /home/joe/share/mary_file_list.txt | mail mary

The  translator might for the benefit   of providing information for a
pipe to mail the end user  the names and  locations of the files print
the following:

file       will be available as
proj1       /home/share/joe/mary/proj1           drwxrwx---  joe      mary
graphic.jpg /home/share/joe/mary/graphic.jpg     -rw-r-----  joe      mary
slides.ps   /home/share/joe/mary/slides.ps       -rw-rw----  joe      mary


Where mary_file_list.txt might contain the following:

# --------------------------------------------------------------------
# source file                translated as    perm       owner    user
# --------------------------------------------------------------------
/home/joe/reports/proj1      proj1           drwxrwx---  joe      mary
/home/joe/images/graphic.jpg graphic.jpg     -rw-r-----  joe      mary
/home/joe/slides/slides.ps   slides.ps       -rw-rw----  joe      mary

What activities will the fileshare translator perform?

1.  settrans   sets  up the  inode  for  joe's  share  directory under
/home/share to invoke the  passive  translator /hurd/fileshare on  the
next access.

2. when the translator is activated,  by an authorized user (mary) the
translator will (via cd or a file open on any of the names.) This node
is owned by joe, but the translator will _only_ allow mary access.

           a. authenticate  the  user using the   port rights for that
           individual.

           b.  if  it  is the appropriate  individual, the permissions
           will be granted for the user via the mechanisms of the port
           requests made to access the  files via the translated  port
           entries. 

Naturally joe will have had to have  granted mary at least execute and
will likely give read access to  the translated inode  so that she can
do directory listing.

           inode  fileshare authenticate
           [mary]     ->    [okay]

                     inode       fileshare action
           [mary] / [report.tex]     ->    [okay]
                                 open

3. When mary types ls at the prompt /home/share/joe/mary she sees:

/home/share/joe/mary/proj1           drwxrwx---  joe      mary
/home/share/joe/mary/graphic.jpg     -rw-r-----  joe      mary
/home/share/joe/mary/slides.ps       -rw-rw----  joe      mary


III. Process Rights Management: Sample application: Confined Email

End  users are affected by  the threat of antagonistic, viral programs
being delivered via email or other mechanisms of information sharing.

Administrators have little success in controlling the end users choice
of   software,  while  simultaneously  maintaining security  for  that
individuals workspace.

Personal and  corporate information  are often  intermixed in  the end
users file space, thus security breaches can compromise more than just
personal information, industry   is motivated  financially to   ensure
their information is secure,  but restrictions for security  often are
inflexible and unduly restrictive.

Virtual  machines have been proposed  as a sandbox mechanism[3]. While
virtual  machines   are one   method,  the performance  costs  seem to
continue to  be  prohibitive,  as well  as   tending to  be   resource
intensive.

Goal two:  Implement a secure  'virtual sandbox' for potentially rogue
processes whose authenticity or  unverifiability make them a threat to
the user.

Example application: confined-email program.

In order to isolate the confined-email program I would like to compose
several translators to produce a virtual sandbox.

My first design of the sandbox will be something like the following.

File space:
pub_key_auth -> chroot ~/email -> fakeuser[4] -> fileshare[5] ->
pub_key_encrypt -> shadowfs

Program Space:

auth ~/.myetc[7] 
      ^
          pub_key_auth -> chroot ~/email -> fakeuser[4] ->
          fileshare /.emailrc [5] -> 
      ^
virtual console
      ^
 email_client

Start up auth with a directory containing the definitions of the local
users and groups  to share files with.   In this case the  argument is
~/.myetc. ~/.myetc contains  passwd,  group, and public key   files of
those users.

pub_key_auth: handles authentication of any requests via public key.

chroot: places the users effective root to  ~/email limiting the scope
of activities to the supplied argument directory[6]

email_client:  has an effective  root  directory of  ~/email, and runs
with permissions limited by the authentication server auth or with the
replacement pub_key_auth, which works  by   validating the user   with
public key authentication, i/o is via the  file share translator which
is mounted on ~/email and supplies / restricts i/o to files defined by
the  configuration file it uses.   It  runs within  a virtual  console
constraining it to the console's io interface (which are authenticated
via the auth server  -- or a user auth  server running with restricted
privileges).

fileshare: reads a startup configuration file /.emailrc from which the
end user  (whose real path  is  ~/email/.emailrc) mail directories are
found. 

IV. Verification: 

 **FIXME**

V. Related discussions.


If I have overlooked places where there is or was prior ideas that you
are aware of, I will appreciate being made aware of them.



Time line: My goal is  to complete a workable  version of the first run
of this translator prior to Jan 1 2003.

   Design:         In progress
   Implementation: Starting from 2002.10.01


Footnotes: 
[1]  https://hurd/security/pre-design.txt
or https://hurd/security/*Article nnml:sent-mail.2002.06*

[2] https://hurd/security/about_the_login_shell.txt The above URL is a
log of the discussion that took place on the debian-hurd mailing list.
I want to acknowledge the dialogue that  took place Starting on August
19, 2002, in a thread begun by Moritz  Schulte titled: About the login
shell, with independently discussing some of these same ideas.

This dialogue came quite close to the file sharing translator ideas, I
had been envisioning, so even  though disorganized, I'm going to point
to the disorganzied draft proposal I had given  my advisor during June
of   this year[1]. 

[3]  **FIXME** references for virtual machine sandbox.

[4]  **FIXME** fakeuser derives from the functionality of fakeroot but
gives the appearance of running as a specific user.

[5] **FIXME** fileshare will be a user configurable translator that
enables exporting files with defined permissions limited to
authenticated users.

[6] I am   not sure yet, if   a fakeuser ==  (fakeroot --user=USER) is
necessary  or  helpful, I  have  been considering  this  as  a way  to
implement a _local_ no_user id that is locked into this environment.

[7]  **FIXME** auth add option for local user and groups files

-- 
/^\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \