lkml.org 
[lkml]   [1998]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Encrypted FS idea

> This is a topic I've been thinking about for awhile. I finally
> decided that perhaps an encrypted FS wasn't the way to go.
...
> As well I can think of all sorts of interesting things to do with
> such a framework (I mentioned my two favorite ACLs and encryption,
> but I've allways been a little interested in transparent file
> versioning as well) It would be best if this could be done on a
> file by file basis, some things there is just no point in encrypting,
> or versioning, and most things work just fine with the traditional
> unix FS permissions. Anyways just some thoughts.

If you want _really_ neat features, look at DG/UX. They are certified
at B1 _with_ the window system and at B2 without. They seem to claim
most of B3 even. (the next closest seem to be SGI and Digital)

As best as I can understand, it goes something like this:


Assign everything two ratings: integrity and sensitivity. For each of the
ratings, add a list of reasons. You get rating pairs like the following:

high(vendor-supplied), high(part-of-os)
low(virus-infected,downloads), low(downloads)
low(downloads), medium(naked-people)
medium(vp-supplied), high(finance,merger-info)

The system keeps administrative users from running trojans in /tmp
because the trojans would _automatically_ get low integrity ratings.
You can put '.' first in $PATH without danger. This is the "Nuke 'em!"
solution to /tmp exploits.

The system keeps crackers from reading secret files because such files
would have a sensitivity rating beyond what the user can access.
It is OK to make /etc/shadow mode 777 and put a copy in the web
server's root directory. The web server can't even see the file.

Security ratings are mandatory. Normal users can only make them more
restrictive. Users that manage sensitive information _can't_ use the
computer to give that information away. The email client knows to
color-code email, the network stack uses IP options to pass security
ratings, the window system won't let a mouse glitch paste secure data
into an IRC session, the printouts display security info at the top
and bottom of each page... It is end-to-end security management.

Security labels look something like this:

__u8 ml_msen_type /* sensitivity */
__u8 ml_mint_type /* integrity */
__u8 ml_level /* sensitivity level (heirarchical part) */
__u8 ml_grade /* integrity grade (heirarchical part) */
__u16 ml_catcount /* sensitivity catagories */
__u16 ml_divcount /* integrity divisions */
__u16 ml_list[] /* divisions seem to follow catagories */

Easy implementation: store labels with the ACL data and privs.
This solution does not properly hide filenames though.

Hard implementation: store labels in the directory, like Digital
Unix does. Maybe this would be easier with Reiserfs and XFS.
Digital uses two 4-byte integers after the filename, perhaps so
that older versions of the operating system can mount a filesystem
read-only. This seems to put high/low security stuff in partially
different namespaces. Don't ask about hard links.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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