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
/ \
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
