viewprinting: what format should views be stored in?

viewprinting: what format should views be stored in?

[Hans Reiser]

It is very important that we have something simple that reuses code for 
this purpose, and it also needs to be scalable.  That is, we need to be 
able to determine in insignificant time whether a file passes through a 
mask consisting of a million files.

One approach would be to use a format similar to that for chroot, that 
is, to keep the format we use for directory trees now, and use it for 
storing the mask.  This raises the question: how would the format for 
the mask differ from that of the underlying filesystem.

Another approach is to use stem compressed names, or some other unique 
within the fs format for the mask.

We need to be able to support specifying a mask that allows any file 
within a given directory to be visible.  That is, we need to support 
dirname/* but we don't yet need to support dirname/foo.*

We probably don't want to allow symbolic links to be followed unless 
where they point to is within the mask.

I want minimal code but I want it to be treelike in its performance 
scalability.

Ideas?

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 3186 bytes --]


First a little (*/tentatively/*) suggested terminology---translation of 
(/tentatively/) I stand
behind it until I begin to suspect I've made a mistake and then I change 
sides ;-) :

1) A *mask *consists of a set of *prescriptions *(trying to avoid rule) 
which defines a
   / subset/ of permissible functionality for a file system.

2) The *permissible functionality *of a file system is roughly speaking, 
the ACLs
    for all the objects in the file system.

    Actually, I think this is a good place to start, because the type 
"permissible
    functionality" is in fact what the mask is applied to and what is 
returned.
   Grant you evaluation is done lazily as the execution of an 
application requires it.

3)  A user and group instantiated mask forms an *operational set of 
functionality*.

     What is important here is to recognize that a given executable may have
     different apparent functionality based on who is running it.

     To make this concept clearer, consider the possibility that group 
write access
     to a file might be elided (masked away) by the some prescription 
for a user
     who otherwise might have add access---but the user's privileges are 
limited
     by the executable.



Hans Reiser wrote:

> It is very important that we have something simple that reuses code 
> for this purpose, and it also needs to be scalable.  That is, we need 
> to be able to determine in insignificant time whether a file passes 
> through a mask consisting of a million files.

A million files or a million rules?  A single rule may give access to a 
million files and
    require only constant time to evaluate.

> One approach would be to use a format similar to that for chroot, that 
> is, to keep the format we use for directory trees now, and use it for 
> storing the mask.  This raises the question: how would the format for 
> the mask differ from that of the underlying filesystem.
>
> Another approach is to use stem compressed names, or some other unique 
> within the fs format for the mask.

Can you elaborate on this for a newbie

>
> We need to be able to support specifying a mask that allows any file 
> within a given directory to be visible.  That is, we need to support 
> dirname/* but we don't yet need to support dirname/foo.*

NB.  Hans and I had discussed limiting access to 'hidden files' 
informally:  '..' in particular needs some
special attention although it would be best not to have a special case 
if we can avoid it.

>
> We probably don't want to allow symbolic links to be followed unless 
> where they point to is within the mask.

Agreed.

> I want minimal code but I want it to be treelike in its performance 
> scalability.
>
> Ideas?

Well, for the moment only more questions:

Suppose we have a file system and a mask.  If we were to create a chroot 
by copying just
the file system accessible through the mask and run the application in 
that environment
would the semantics of running the application on the original file 
system with the mask
by equivalent.  By equivalent I mean no observable difference in the 
instructions executed
at the user level or the output generated.

Does the question make sense?


[-- Attachment #2: Type: text/html, Size: 4297 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
> First a little (*/tentatively/*) suggested terminology---translation 
> of (/tentatively/) I stand
> behind it until I begin to suspect I've made a mistake and then I 
> change sides ;-) :
>
> 1) A *mask *consists of a set of *prescriptions *(trying to avoid 
> rule) which defines a
>    / subset/ of permissible functionality for a file system.
>
> 2) The *permissible functionality *of a file system is roughly 
> speaking, the ACLs
>     for all the objects in the file system.
>
>     Actually, I think this is a good place to start, because the type 
> "permissible
>     functionality" is in fact what the mask is applied to and what is 
> returned.
>    Grant you evaluation is done lazily as the execution of an 
> application requires it.
>
Yes.

> 3)  A user and group instantiated mask forms an *operational set of 
> functionality*.
>
>      What is important here is to recognize that a given executable 
> may have
>      different apparent functionality based on who is running it.

I think not in our particular niche.  We do process oriented security, 
and that is all for now.  Later we can make it more complex.

>
>      To make this concept clearer, consider the possibility that group 
> write access
>      to a file might be elided (masked away) by the some prescription 
> for a user
>      who otherwise might have add access---but the user's privileges 
> are limited
>      by the executable.
>
>
>
> Hans Reiser wrote:
>
>> It is very important that we have something simple that reuses code 
>> for this purpose, and it also needs to be scalable.  That is, we need 
>> to be able to determine in insignificant time whether a file passes 
>> through a mask consisting of a million files.
>
> A million files or a million rules

filenames actually.

>   A single rule may give access to a million files and
>     require only constant time to evaluate.
>
>> One approach would be to use a format similar to that for chroot, 
>> that is, to keep the format we use for directory trees now, and use 
>> it for storing the mask.  This raises the question: how would the 
>> format for the mask differ from that of the underlying filesystem.
>>
>> Another approach is to use stem compressed names, or some other 
>> unique within the fs format for the mask.
>
> Can you elaborate on this for a newbie

fired
fireman
fireplace
get stored as
fired
!4man
!4place
if we use classic stem compression, if we use a tree that branches where 
the names diverge (I forget, is that a radix tree or?) then we have 
another structure.

>>
>> We need to be able to support specifying a mask that allows any file 
>> within a given directory to be visible.  That is, we need to support 
>> dirname/* but we don't yet need to support dirname/foo.*
>
> NB.  Hans and I had discussed limiting access to 'hidden files' 
> informally:  '..' in particular needs some
> special attention although it would be best not to have a special case 
> if we can avoid it.

We can treat .. the same as we treat symboplic links.

>>
>> We probably don't want to allow symbolic links to be followed unless 
>> where they point to is within the mask.
>
> Agreed.
>
>> I want minimal code but I want it to be treelike in its performance 
>> scalability.
>>
>> Ideas?
>
> Well, for the moment only more questions:
>
> Suppose we have a file system and a mask.  If we were to create a 
> chroot by copying just
> the file system 

semantic tree (not files, just filenames)

> accessible through the mask and run the application in that environment
> would the semantics of running the application on the original file 
> system with the mask
> by equivalent.  By equivalent I mean no observable difference in the 
> instructions executed
> at the user level or the output generated.

No, because new files might be made visible through the mask without the 
new file creator even being aware that there was a mask.

>
> Does the question make sense?
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

>
>>> Another approach is to use stem compressed names, or some other 
>>> unique within the fs format for the mask.
>>
>>
>> Can you elaborate on this for a newbie
>
>
> fired
> fireman
> fireplace
> get stored as
> fired
> !4man
> !4place
> if we use classic stem compression, if we use a tree that branches 
> where the names diverge (I forget, is that a radix tree or?) then we 
> have another structure.

Trie I think is what you mean.  http://www.nist.gov/dads/HTML/trie.html

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]



Hans Reiser wrote:

> George Beshers wrote:
>
>> 2) The *permissible functionality *of a file system is roughly 
>> speaking, the ACLs
>>     for all the objects in the file system.
>>
>>     Actually, I think this is a good place to start, because the type 
>> "permissible
>>     functionality" is in fact what the mask is applied to and what is 
>> returned.
>>    Grant you evaluation is done lazily as the execution of an 
>> application requires it.
>>
> Yes.

I have started re-reading withe Single UNIX Specification with getting a 
working
definition of permissible functionality in mind.  Have not gotten to 
Usenix papers
yet or a careful search of ACM.

Does anyone think there is a better starting point?  Or things that are 
particularly
important to consider?

>
>> 3)  A user and group instantiated mask forms an *operational set of 
>> functionality*.
>>
>>      What is important here is to recognize that a given executable 
>> may have
>>      different apparent functionality based on who is running it.
>
>
> I think not in our particular niche.  We do process oriented security, 
> and that is all for now.  Later we can make it more complex.

We can't avoid it at some level without re-writing Linux security.  Take 
a moment to consider
the set-UID bit on a file which is an executable and I think you will 
see what I am driving at.

That said, all we need to do is make our specification conform to the 
smallest code change
for the time being, e.g., the identity mask---what was happening before 
is what you get.

NB.  I understand that the overriding goal of the first 3 months is 
devising and demonstrating
that we have a strategy that scales to file systems containing millions 
of files---but I don't
think we can lose any semantics as fundamental as user/group permissions 
without inviting
criticism.


>
>>
>>
>>
>> Well, for the moment only more questions:
>>
>> Suppose we have a file system and a mask.  If we were to create a 
>> chroot by copying just
>> the file system 
>
>
> semantic tree (not files, just filenames)
>
>> accessible through the mask and run the application in that environment
>> would the semantics of running the application on the original file 
>> system with the mask
>> by equivalent.  By equivalent I mean no observable difference in the 
>> instructions executed
>> at the user level or the output generated.
>
>
> No, because new files might be made visible through the mask without 
> the new file creator even being aware that there was a mask.

I don't think my question was very clear ...

For any process, could that process determine if it was running

    * on a reiser4 file system that is really the root
    * on a reiser4 file system with a mask, or
    * on a reiser4 file system with chroot

/exclusively/ by making calls to the reiser4 file system?

>
>>
>> Does the question make sense?
>
Uh no... :-[


[-- Attachment #2: Type: text/html, Size: 4144 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>>
>>> 3)  A user and group instantiated mask forms an *operational set of 
>>> functionality*.
>>>
>>>      What is important here is to recognize that a given executable 
>>> may have
>>>      different apparent functionality based on who is running it.
>>
>>
>> I think not in our particular niche.  We do process oriented 
>> security, and that is all for now.  Later we can make it more complex.
>
> We can't avoid it at some level without re-writing Linux security.  
> Take a moment to consider
> the set-UID bit on a file which is an executable and I think you will 
> see what I am driving at.

I don't see what you are saying.  Our mask does process oriented 
security.  The underlying security remains a user/object/permission mapping.

>
> That said, all we need to do is make our specification conform to the 
> smallest code change
> for the time being, e.g., the identity mask---what was happening 
> before is what you get.

Well, we should just pass things through the mask to whatever is below.

>
> NB.  I understand that the overriding goal of the first 3 months is 
> devising and demonstrating
> that we have a strategy that scales to file systems containing 
> millions of files---but I don't
> think we can lose any semantics as fundamental as user/group 
> permissions without inviting
> criticism.

We are not losing, we are residing above and masking them.

>
>
>>
>>>
>>>
>>>
>>> Well, for the moment only more questions:
>>>
>>> Suppose we have a file system and a mask.  If we were to create a 
>>> chroot by copying just
>>> the file system 
>>
>>
>> semantic tree (not files, just filenames)
>>
>>> accessible through the mask and run the application in that environment
>>> would the semantics of running the application on the original file 
>>> system with the mask
>>> by equivalent.  By equivalent I mean no observable difference in the 
>>> instructions executed
>>> at the user level or the output generated.
>>
>>
>> No, because new files might be made visible through the mask without 
>> the new file creator even being aware that there was a mask.
>
> I don't think my question was very clear ...
>
> For any process, could that process determine if it was running
>
>     * on a reiser4 file system that is really the root
>
the root filesystem?

>    *
>
>
>     * on a reiser4 file system with a mask, or
>     * on a reiser4 file system with chroot
>
> /exclusively/ by making calls to the reiser4 file system?

Hmm, sounds like the answer requires carefully traversing the code.;-)

>
>>
>>>
>>> Does the question make sense?
>>
> Uh no... :-[
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> George Beshers wrote:
>
>> We can't avoid it at some level without re-writing Linux security.  
>> Take a moment to consider
>> the set-UID bit on a file which is an executable and I think you will 
>> see what I am driving at.
>
>
> I don't see what you are saying.  Our mask does process oriented 
> security.  The underlying security remains a user/object/permission 
> mapping.
>
The issue is how the mask might change the semantics of sys_execve().  I 
have spent some time
starting to trace code around, but more work is required.

For the moment I think we are safe if the setuid and setgroup can not be 
altered by the mask.

We only change the semantics if the real/effective uid or gid is 
different at some point in the
processes execution because of the mask---begging situations where a 
call to setuid happens
only if a certain file is not available.

I want to get back to understanding your second proposed strategy.


>

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>> George Beshers wrote:
>>
>>> We can't avoid it at some level without re-writing Linux security.  
>>> Take a moment to consider
>>> the set-UID bit on a file which is an executable and I think you 
>>> will see what I am driving at.
>>
>>
>>
>> I don't see what you are saying.  Our mask does process oriented 
>> security.  The underlying security remains a user/object/permission 
>> mapping.
>>
> The issue is how the mask might change the semantics of sys_execve().  
> I have spent some time
> starting to trace code around, but more work is required.
>
> For the moment I think we are safe if the setuid and setgroup can not 
> be altered by the mask.

Ok.

>
> We only change the semantics if the real/effective uid or gid is 
> different at some point in the
> processes execution because of the mask---begging situations where a 
> call to setuid happens
> only if a certain file is not available.

Say more.

>
> I want to get back to understanding your second proposed strategy.
>
>
>>
>
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]


First, rereading my e-mails I realize that there was some thinking 
behind my questions
which was only partially articulated.  Going back to my earlier position 
which I will restate
here as:

    /Use of a mask should never corrupt the semantics defined by the
    Single Unix
    Specification /*or*/ its practical derivations and extensions, e.g.,
    BSD and Linux./

That is,/ ideally/ if I created a standalone system that "looked" like 
the system the mask
provides then the process would behave equivalently.  I emphasize 
ideally because to
actually make that the case would require something closer to a virtual 
machine---which
is clearly beyond the scope of this project.

So I am looking for potential semantic anomalies which could be 
introduced by a
mask over a reiser4 file system, i.e., border cases where some upfront 
awareness
and attention may save re-design and re-writing later on.


Hans Reiser wrote:

>
>> The issue is how the mask might change the semantics of 
>> sys_execve().  I have spent some time
>> starting to trace code around, but more work is required.
>>
>> For the moment I think we are safe if the setuid and setgroup can not 
>> be altered by the mask.
>
>
> Ok.


For the moment I will focus on how the uid (and assume the group id will 
be similar)
of a process and how the mask might lead to a different uid than would 
be expected
under standard semantics.

So we agree that the process has an associated user: actually there is 
the concept
of real and effective uid also.

I believe the statement above to be true if the process never makes a 
setuid() system's call of
one flavor or another because the uid is inherited from the process 
calling execev() or is determined
by the owner of the executable if the executable's file set-uid 
permission bit is turned on via chmod.

>>
>> We only change the semantics if the real/effective uid or gid is 
>> different at some point in the
>> processes execution because of the mask---begging situations where a 
>> call to setuid happens
>> only if a certain file is not available.
>
>
> Say more.

If the process has the code like

    if (stat("/etc/foobar.conf", statbuf)  < 0) {
         if (setuid(3) < 0) {   /* Try to become sys */
        }
        /* Do something here */
    }

And the mask hides "/etc/foobar.conf" then in fact the uid
will change but *not unexpectedly*, IMO.  The mask is
creating a changed environment but the behavior is
understandable from the source code.

Put this another way, the semantics still seem correct to me
because you are getting the behavior of "/etc/foobar.conf" actually
not being there.

Now that I think about it masking a named pipe or a lock file
is perhaps more likely to cause problems then the setuid bit.
More cogitation required...  :-)



[-- Attachment #2: Type: text/html, Size: 3669 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
> First, rereading my e-mails I realize that there was some thinking 
> behind my questions
> which was only partially articulated.  Going back to my earlier 
> position which I will restate
> here as:
>
>     /Use of a mask should never corrupt the semantics defined by the
>     Single Unix
>     Specification /*or*/ its practical derivations and extensions,
>     e.g., BSD and Linux./
>
I expect to turn those semantics on their head within 3-5 years when we 
do the semantic enhancements.

I think you should rephrase it as: we should not break any existing 
program without getting something sufficiently worthwhile as a result, 
and doing it with care.

> That is,/ ideally/ if I created a standalone system that "looked" like 
> the system the mask
> provides then the process would behave equivalently.  I emphasize 
> ideally because to
> actually make that the case would require something closer to a 
> virtual machine---which
> is clearly beyond the scope of this project.
>
> So I am looking for potential semantic anomalies which could be 
> introduced by a
> mask over a reiser4 file system, i.e., border cases where some upfront 
> awareness
> and attention may save re-design and re-writing later on.
>
>
> Hans Reiser wrote:
>
>>
>>> The issue is how the mask might change the semantics of 
>>> sys_execve().  I have spent some time
>>> starting to trace code around, but more work is required.
>>>
>>> For the moment I think we are safe if the setuid and setgroup can 
>>> not be altered by the mask.
>>
>>
>> Ok.
>
>
> For the moment I will focus on how the uid (and assume the group id 
> will be similar)
> of a process and how the mask might lead to a different uid than would 
> be expected
> under standard semantics.

I don't think you need to support the mask changing uids.  Nice feature, 
but let's keep it minimal for now.  I think the whole issue of uid can 
be sidestepped and ignored.  You can, however, put 3 paragraphs in our 
report discussing it as a theoretical issue, if you find it interesting 
to ponder.

>
> So we agree that the process has an associated user: actually there is 
> the concept
> of real and effective uid also.
>
> I believe the statement above to be true if the process never makes a 
> setuid() system's call of
> one flavor or another because the uid is inherited from the process 
> calling execev() or is determined
> by the owner of the executable if the executable's file set-uid 
> permission bit is turned on via chmod.
>
>>>
>>> We only change the semantics if the real/effective uid or gid is 
>>> different at some point in the
>>> processes execution because of the mask---begging situations where a 
>>> call to setuid happens
>>> only if a certain file is not available.
>>
>>
>> Say more.
>
> If the process has the code like
>
>     if (stat("/etc/foobar.conf", statbuf)  < 0) {
>          if (setuid(3) < 0) {   /* Try to become sys */
>         }
>         /* Do something here */
>     }
>
> And the mask hides "/etc/foobar.conf" then in fact the uid
> will change but *not unexpectedly*, IMO.  The mask is
> creating a changed environment but the behavior is
> understandable from the source code.
>
> Put this another way, the semantics still seem correct to me
> because you are getting the behavior of "/etc/foobar.conf" actually
> not being there.
>
> Now that I think about it masking a named pipe or a lock file
> is perhaps more likely to cause problems then the setuid bit.
> More cogitation required...  :-)
>
It is not our task to ensure the mask causes no problems due to a faulty 
specification of it.  It is merely our task to ensure that creating a 
correct mask is well automated and easy.

George, trust me, the project will be a LOT more fun if we implement the 
bare minimum and get it done early, and then after that spend the rest 
of the time doing what amuses us.

For me, the big issue to decide at the start is, should a view 
specification be implemented with a format that is as if it is a 
subdirectory of the masked executable, and that the executable gets 
chrooted to, and that uses all the semantic tree traversal code already 
written by us.

I think the answer is yes, but I am going to think about it as I jog for 
an hour.  Please come up with arguments for and against it.

Hans

Re: viewprinting: what format should views be stored in? (let me quickly correct an imprecision)

[Hans Reiser]

Let me instead of the previous email, say:

For me, the big issue to decide at the start is, should a view 
specification be implemented with a format that is as if it is a 
subdirectory of the masked executable, and which we then take the 
filenames used by the executable and traverse the subdirectory as though 
it was root, and if we reach a valid fall through point, then allow we 
traverse from the real filesystem root, and if not, we issue a suitable 
error.

This would let us use all the semantic tree traversal code already 
written by us.

It would however require us to add such plugins as "fall through 
points", and "prints", etc.  If really lucky, you could have some 
working plugins in 4 months, and maybe have masking software done by the 
end of the contract.

I think the answer is yes, we want to do it this way, but I am going to 
think about it as I jog for an hour.  Please come up with arguments for 
and against it.

>
> Hans
>

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>>
>>>>
>>>> No, because new files might be made visible through the mask 
>>>> without the new file creator even being aware that there was a mask.
>>>
>>>
>>> I don't think my question was very clear ...
>>>
>>> For any process, could that process determine if it was running
>>>
>>>     * on a reiser4 file system that is really the root
>>>
>> the root filesystem?
>
> Yes, as understood by the OS.
>
>>
>>>    *
>>>
>>>
>>>     * on a reiser4 file system with a mask, or
>>>     * on a reiser4 file system with chroot
>>>
>>> /exclusively/ by making calls to the reiser4 file system?
>>
>>
>> Hmm, sounds like the answer requires carefully traversing the code.;-)
>
> of course :-)
>

> But what would we like the answer to be?

Ah, so that is the question....

>     I will take the position that "no the process can not tell" as
>     being useful
>     because it makes running with a mask a better test environment.
>     Also, I don't see how cluing the process in that a mask is in
>     place can
>     improve security whereas knowing that the mask is in place might
>     encourage someone to try to work around it (beyond the filesystem
>     semantics).
>
>
>
Yes, you are right I think, but you should ask on the mailing list what 
information about what is the root filesystem is used for by the OS

Re: viewprinting: what format should views be stored in?

[David Dabbs]

Hans and George,

I've been lurking at the edge of this discussion and have not chimed in 
mostly because I only have a dial-up connection here at my in-laws
house (and I'm suposed to be on vacation). Since there was a request for 
arguments for or against Hans's preferred approach, I thought I'd add 
my $0.02.

In order to put everything into perspective as well as to provide context
for some questions, I attempted to distill concrete items or decisions from 
the last several days' exchanges.

As to arguments For or Against; 
For
If you only have three months to prove a concept and obtain continued 
funding, then I agree with Hans's preference for reusing as much 
existing work as possible. Adapting Hans's statement regarding 
[in]compatibility, "...if we [write new code] we should do 
so only if it is sufficiently worthwhile." 

Against
I can think of none at this point, given my understanding of 
the features. 


Project
----------------------------------------------------------------------
Demonstrate process-oriented filesystem viewprinting that scales to 
filesystems (and masks) containing millions of files. Provide 
exec-time mask application as well as tools for automating mask 
creation and maintenance.


Definitions
---------------------------------------------------------------------
Process-Oriented
Specifications of filesystem object visibility are applied to processes 
regardless of the effective user rights with which the process runs.

Mask (or viewprint)
A specification as to which files are visible to process[es] 
"running under" the mask. The [file] security underlying the mask
remains a user/object/permission mapping. If a mask a) does not 
include a file or b) explicitly filters out acess, the file operation ceases
and an error is returned. If the file upon which the process wants to 
operate is not filtered by the mask, then the operation request is 
passed on to the underlying filesystem. There, the requested file 
a) might not exist, b) might exist but not be visible/readable by the 
user running the process, etc. 

Fall-Through Point
The point during some file operation at which it is determined that the 
file is not filtered by the mask. The request [for operation X on the file]
is passed on to the VFS/underlying filesystem. 



Features & Performance (Qualitative/Soft)
----------------------------------------------------------------------
It is...our task to ensure that creating a correct mask is well automated 
and easy.

We do process oriented security, and that is all for now. The underlying 
[file] security remains a user/object/permission mapping.

We need to be able to determine in insignificant time whether a file 
"passes through" a mask consisting of a million filenames.

..if we must break an existing program we should do so only with care 
and only if it is sufficiently worthwhile to do so. 


Features & Performance (Quantitative/Hard)
----------------------------------------------------------------------
Masks 
- must support dirname/* 
- do not [yet] need to support dirname/foo.*
- should not allow symbolic link traversal unless the file pointed to 
   is within the mask.
- (by extension) should not allow hard links unless the file 
  pointed to is within the mask.



Hans's Initial Considerations & Design Proposal
----------------------------------------------------------------------
[The solution] must be treelike in its performance scalability.

It is very important that we have something simple that reuses code for 
this purpose. The big issue to decide at the start is, should a view 
specification be implemented with a format that is as if it is a 
subdirectory of the masked executable, and which we then take the 
filenames used by the executable and traverse the subdirectory as 
though it was root, and if we reach a valid fall through point, then 
allow [us to] traverse from the real filesystem root, and if not, 
we issue a suitable error.

This would let us use all the existing semantic tree traversal code.
It would, however, require us to add such plugins as "fall through points", 
and "prints", etc.  I think the answer is yes, we want to do it this way.  
Please come up with arguments for and against it.



Questions
----------------------------------------------------------------------
Handwaving for a moment over view creation and storage particulars, it
is pretty clear that this new security feature will rely upon reiser4 
for masking. Does this mean that one will only be able to mask a 
reiser4 filesystem, or will any VFS fs be "maskable?"

All file types and access methods will be supported, yes? 
(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)

In the original proposal posted to the list Hans (I think) referred to 
viewprinting as "chroot on steroids." Let's assume that the mask 
creation tools deliver on making viewprint creation and maintainance 
very easy/painless for admins. In what way will viewprinting be more 
secure than chroot? 

If I understand the ways admins use chroot, or would like to use it, 
then should the design include "stackable" or "inheritable" masks? 
This is not unlike stackable filesystems or filter pipelines. If, 
for instance, most processes need to see /usr/local/lib/* and 
/usr/local/bin/*, then this spec is in a 'base' mask and the mask 
for /usr/local/bin/fooprocess would inhert from and add to this 
base specification.

Early on in the conversation, there was discussion about 
"permissible functionality." At a minimum, a mask, true to its name, 
will effect filesystem object _visibility_. It was not completely 
clear whether the mask will be proscriptive viz operations. IOW, will 
the mask say that fooprocess "is not permitted to [attempt to] RWX 
object bar?" I believe this is not something masks will do, but I 
wanted clarification.

Hans, in your preferred approach you referred to "a format that 
is as if it is a subdirectory of the masked executable." Did you have
in mind checking for something like /usr/bin/fooprocess/metas/mask 
when exec() loads the exe, and if this exists then the files rooted 
in this directory would be set as the process's root filesystem?

Are masks capable of explicit exclusion as well as inclusion?
If the answer is 'Yes,' then what are your thoughts as to how this 
might be accommodated when your main tool is reiser4's semantic 
tree layer? Inclusion would be straightforward -- if the directory 
exists or the name exists within the directory then fall through. 
But exclusion? If you are limited to the semantic layer, then there's 
no stat node with which to play tricks. 

I wonder if it would be feasible if masks only specified 
exclusions? If, for instance, the mask wanted to exclude /foo/*, 
then the directory foo would exist (in the mask semantic tree). 
To exclude /etc/passwd, passwd would exist in the directory /etc. 
Since you're already going to need to preempt dcache searches 
(aren't you?) you can insert a search of the mask tree. If the 
search fails, then it is not excluded and the request falls through 
to normal VFS handling. In the /etc/passwd case above, it would find 
/etc/passwd and so the file is excluded. Processing would stop there, returning some error. How does this sound? I need to sleep on this, 
because it is very late here.


David

Re: viewprinting: what format should views be stored in?

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Dabbs wrote:
| If you only have three months to prove a concept and obtain continued
| funding, then I agree with Hans's preference for reusing as much
| existing work as possible. Adapting Hans's statement regarding
I've also been lurking and not reading too much, but here's my thought:
It is far more important to create code which can easily be re-used in
the future than to re-use code that you have now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQSOh8ngHNmZLgCUhAQKGGBAAhIOpJGCU2qcknOIjJ1qUdYEVOoqUIi8R
85G4WzVbJm/q73N/gaIhvyYfpRz6dvLdcfLoLkg2NbYcOfL7g54TrmKzEF6wsbQb
9SVE6zkrffqlclDUV7vkaIv1ZtipMDhbpWqLXM0UNiGvyNq1ltVazOQxdI9ptmC6
f9xj/EkwWT35PDddTLk8pEp0wa1D3WhBc+IjFPKplSD/eoHwfypAU/Hfbcrj80F7
wNdgEv9/kYUcgRqCoZcCoEODoBgiol5hcbVg44RdAyQVUhqJHV0rOqmZJ3llLQBR
EEnoqLTdPgmF8OnZUJ6GRfgKIeQsXy0OQ4Dl4r8YbxbanAaUSdMEacKclgyY7GeX
Y72/XiEr6WR4SumdckgHdTkMlwxJPndUeUC4L2f/ZpK+f7A3PAU6IjguxSy7vHU7
2LffTf8xkGegR9hwlgDwRFuyyZTaYqRqU/5h04lheUFhu5E43gI/N3NsR9+gkDdc
IXEW1n+UCMgUrxLW+9VnvujOruDHDkrjDUgEBENBQOmksJfq1nc6o48jbWtOjnVD
Wp1nD6CIGdcmGLXIXhKXZYwLKNrrGFVPd9xwQRjmuTU0DtoYBCA7t6ezyhzGcQYs
UtEtGaDJXiiYZCL9sXwjrwx3Pag06Zc12icqlPSfddiSufQeesokEG7hiD2kP2G0
2SURGS8gjhs=
=AXNc
-----END PGP SIGNATURE-----

Re: viewprinting: what format should views be stored in?

[George Beshers]

David Masover wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Dabbs wrote:
> | If you only have three months to prove a concept and obtain continued
> | funding, then I agree with Hans's preference for reusing as much
> | existing work as possible. Adapting Hans's statement regarding
> I've also been lurking and not reading too much, but here's my thought:
> It is far more important to create code which can easily be re-used in
> the future than to re-use code that you have now.
>
Point taken, but based on my initial reading I think that there is more to
be saved and than redone to improve the re-use of the existing code.

Re: viewprinting: what format should views be stored in?

[George Beshers]

Thanks for joining the discussion.  I have answered your questions
as best I can for the moment---which in fact has been to make some
further points and encourage you and others to ask more questions
and make more suggestions :-)


David Dabbs wrote:

>
>Questions
>----------------------------------------------------------------------
>Handwaving for a moment over view creation and storage particulars, it
>is pretty clear that this new security feature will rely upon reiser4 
>for masking. Does this mean that one will only be able to mask a 
>reiser4 filesystem, or will any VFS fs be "maskable?"
>  
>
As a proof of concept reiser4---although I think that the ability to 
work with
multiple reiser4 mounted filesystems is relevant and important.

>All file types and access methods will be supported, yes? 
>(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)
>  
>
That is the plot.  Again, we are taking the point of view that the proof 
of concept
does not need to be complete; links however are included.

>In the original proposal posted to the list Hans (I think) referred to 
>viewprinting as "chroot on steroids." Let's assume that the mask 
>creation tools deliver on making viewprint creation and maintainance 
>very easy/painless for admins. In what way will viewprinting be more 
>secure than chroot?
>  
>
Basically, chroot as I at least normally use it, has a lot of baggage in 
terms of
disk consumption that we are planning to avoid by creating a view rather 
than
a copy.  Second, users always interact with a system via executables so
normally the executables have taken on the security attributes of the user
(set-UID being the major exception on Unix) but, to some extent, we are
developing a new semantic.

While views for DBMS, ClearCase, etc. have been around for a long time
attaching access lists to process seems to be semi-virgin territory, at
least for Unix systems.

Any and all pointers to references to prove me wrong appreciated :-)

>If I understand the ways admins use chroot, or would like to use it, 
>then should the design include "stackable" or "inheritable" masks? 
>This is not unlike stackable filesystems or filter pipelines. If, 
>for instance, most processes need to see /usr/local/lib/* and 
>/usr/local/bin/*, then this spec is in a 'base' mask and the mask 
>for /usr/local/bin/fooprocess would inhert from and add to this 
>base specification.
>  
>
Something like this had occurred to me, but I think that for a proof of 
concept
having the tools that assist the user in creating the mask make it easy to
include these but have each actual mask on disk be a standalone entity is
the way to go.

I think that inherited masks from a parent process are a much stronger
requirement---think about restricted shell.

All questions which keep me from wasting time on an overly simplistic
approach welcome :-)

>Early on in the conversation, there was discussion about 
>"permissible functionality." At a minimum, a mask, true to its name, 
>will effect filesystem object _visibility_. It was not completely 
>clear whether the mask will be proscriptive viz operations. IOW, will 
>the mask say that fooprocess "is not permitted to [attempt to] RWX 
>object bar?" I believe this is not something masks will do, but I 
>wanted clarification.
>  
>
The attempt will be blocked with a suitable error return from the system 
call,
it is the responsibility of the mask administrator to get this right.

There are many interesting application correctness and/or mask correctness
questions which will need a lot more thought to bring to fruition.

>Hans, in your preferred approach you referred to "a format that 
>is as if it is a subdirectory of the masked executable." Did you have
>in mind checking for something like /usr/bin/fooprocess/metas/mask 
>when exec() loads the exe, and if this exists then the files rooted 
>in this directory would be set as the process's root filesystem?
>
>Are masks capable of explicit exclusion as well as inclusion?
>If the answer is 'Yes,' then what are your thoughts as to how this 
>might be accommodated when your main tool is reiser4's semantic 
>tree layer? Inclusion would be straightforward -- if the directory 
>exists or the name exists within the directory then fall through. 
>But exclusion? If you are limited to the semantic layer, then there's 
>no stat node with which to play tricks. 
>  
>
I think the correct answer is "anything not explicitly included is excluded"
or on the other side of the looking glass "anything not explicitly excluded
is included".

As a user friendly interface both should be supported and the "compilation"
layer handle the conversion.

Maybe I am not understanding the question.

>I wonder if it would be feasible if masks only specified 
>exclusions? If, for instance, the mask wanted to exclude /foo/*, 
>then the directory foo would exist (in the mask semantic tree). 
>To exclude /etc/passwd, passwd would exist in the directory /etc. 
>Since you're already going to need to preempt dcache searches 
>(aren't you?) you can insert a search of the mask tree. If the 
>search fails, then it is not excluded and the request falls through 
>to normal VFS handling. In the /etc/passwd case above, it would find 
>/etc/passwd and so the file is excluded. Processing would stop there, returning some error. How does this sound? I need to sleep on this, 
>because it is very late here.
>  
>
At this time I think feasible is true and useful is an open question.

To address the useful I find that known/desirable use-case scenarios
get the most discussion.

To give a couple of examples:
     1) A given process (say a restricted shell) can not exec() an
         executable with the set-uid bit on.
          - directly
          - indirectly (e.g., via bash)
     2) Apache can only create/write files in /var/web/incoming.
          - files created or modified can not have any execute bit set 
and executing chmod is excluded.

This will be the topic of many future e-mails I am sure. ;-)

>
>David
>
>  
>

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
> Thanks for joining the discussion.  I have answered your questions
> as best I can for the moment---which in fact has been to make some
> further points and encourage you and others to ask more questions
> and make more suggestions :-)
>
>
> David Dabbs wrote:
>
>>
>> Questions
>> ----------------------------------------------------------------------
>> Handwaving for a moment over view creation and storage particulars, it
>> is pretty clear that this new security feature will rely upon reiser4 
>> for masking. Does this mean that one will only be able to mask a 
>> reiser4 filesystem, or will any VFS fs be "maskable?"
>>  
>>
> As a proof of concept reiser4---although I think that the ability to 
> work with
> multiple reiser4 mounted filesystems is relevant and important.
>
>> All file types and access methods will be supported, yes? (mmap, AIO, 
>> DIRECT, pipes, hard/sym links, etc.)
>>  
>>
> That is the plot.  Again, we are taking the point of view that the 
> proof of concept
> does not need to be complete; links however are included.
>
>> In the original proposal posted to the list Hans (I think) referred 
>> to viewprinting as "chroot on steroids." Let's assume that the mask 
>> creation tools deliver on making viewprint creation and maintainance 
>> very easy/painless for admins. In what way will viewprinting be more 
>> secure than chroot?
>>  
>>
> Basically, chroot as I at least normally use it, has a lot of baggage 
> in terms of
> disk consumption that we are planning to avoid by creating a view 
> rather than
> a copy.

Chroot lacks fall through points.

> Second, users always interact with a system via executables so
> normally the executables have taken on the security attributes of the 
> user
> (set-UID being the major exception on Unix) but, to some extent, we are
> developing a new semantic.
>
> While views for DBMS, ClearCase, etc. have been around for a long time
> attaching access lists to process seems to be semi-virgin territory, at
> least for Unix systems.
>
> Any and all pointers to references to prove me wrong appreciated :-)
>
>> If I understand the ways admins use chroot, or would like to use it, 
>> then should the design include "stackable" or "inheritable" masks? 
>> This is not unlike stackable filesystems or filter pipelines. If, for 
>> instance, most processes need to see /usr/local/lib/* and 
>> /usr/local/bin/*, then this spec is in a 'base' mask and the mask for 
>> /usr/local/bin/fooprocess would inhert from and add to this base 
>> specification.
>>  
>>
> Something like this had occurred to me, but I think that for a proof 
> of concept
> having the tools that assist the user in creating the mask make it 
> easy to
> include these but have each actual mask on disk be a standalone entity is
> the way to go.
>
> I think that inherited masks from a parent process are a much stronger
> requirement---think about restricted shell.
>
> All questions which keep me from wasting time on an overly simplistic
> approach welcome :-)
>
>> Early on in the conversation, there was discussion about "permissible 
>> functionality." At a minimum, a mask, true to its name, will effect 
>> filesystem object _visibility_. It was not completely clear whether 
>> the mask will be proscriptive viz operations. IOW, will the mask say 
>> that fooprocess "is not permitted to [attempt to] RWX object bar?" I 
>> believe this is not something masks will do, but I wanted clarification.
>>  
>>
> The attempt will be blocked with a suitable error return from the 
> system call,
> it is the responsibility of the mask administrator to get this right.
>
> There are many interesting application correctness and/or mask 
> correctness
> questions which will need a lot more thought to bring to fruition.
>
>> Hans, in your preferred approach you referred to "a format that is as 
>> if it is a subdirectory of the masked executable." Did you have
>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>> when exec() loads the exe, and if this exists then the files rooted 
>> in this directory would be set as the process's root filesystem?
>>
>> Are masks capable of explicit exclusion as well as inclusion?
>> If the answer is 'Yes,' then what are your thoughts as to how this 
>> might be accommodated when your main tool is reiser4's semantic tree 
>> layer? Inclusion would be straightforward -- if the directory exists 
>> or the name exists within the directory then fall through. But 
>> exclusion? If you are limited to the semantic layer, then there's no 
>> stat node with which to play tricks.  
>>
> I think the correct answer is "anything not explicitly included is 
> excluded"
> or on the other side of the looking glass "anything not explicitly 
> excluded
> is included".
>
> As a user friendly interface both should be supported and the 
> "compilation"
> layer handle the conversion.
>
> Maybe I am not understanding the question.

clearcase has an exclude operation for its view specifications.

>
>> I wonder if it would be feasible if masks only specified exclusions? 
>> If, for instance, the mask wanted to exclude /foo/*, then the 
>> directory foo would exist (in the mask semantic tree). To exclude 
>> /etc/passwd, passwd would exist in the directory /etc. Since you're 
>> already going to need to preempt dcache searches (aren't you?) you 
>> can insert a search of the mask tree. If the search fails, then it is 
>> not excluded and the request falls through to normal VFS handling. In 
>> the /etc/passwd case above, it would find /etc/passwd and so the file 
>> is excluded. Processing would stop there, returning some error. How 
>> does this sound? I need to sleep on this, because it is very late here.
>>  
>>
> At this time I think feasible is true and useful is an open question.
>
> To address the useful I find that known/desirable use-case scenarios
> get the most discussion.
>
> To give a couple of examples:
>     1) A given process (say a restricted shell) can not exec() an
>         executable with the set-uid bit on.
>          - directly
>          - indirectly (e.g., via bash)
>     2) Apache can only create/write files in /var/web/incoming.
>          - files created or modified can not have any execute bit set 
> and executing chmod is excluded.

this protection happens while traversing the mask or at the fall through 
point.  Hmmm, we need to accumulate a set of permissions that apply to 
something that are specific to how we got there.  That could be complex 
in the VFS details.  We can defer it to Phase II if necessary.  George, 
you should spend a day (not this week) figuring out how much work it 
would be to make that work.  It will be the details of it that will be 
dangerous....

>
> This will be the topic of many future e-mails I am sure. ;-)
>
>>
>> David
>>
>>  
>>
>
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> George Beshers wrote:
>
>>
>> David Dabbs wrote:
>>
>>> In the original proposal posted to the list Hans (I think) referred 
>>> to viewprinting as "chroot on steroids." Let's assume that the mask 
>>> creation tools deliver on making viewprint creation and maintainance 
>>> very easy/painless for admins. In what way will viewprinting be more 
>>> secure than chroot?
>>>  
>>>
>> Basically, chroot as I at least normally use it, has a lot of baggage 
>> in terms of
>> disk consumption that we are planning to avoid by creating a view 
>> rather than
>> a copy.
>
>
> Chroot lacks fall through points.

Other than saving disk space is this important?

Are you thinking about multiple processes, with different views, but
sharing a few "resources", i.e., files of one form or another as part of
a long term vision?

>
>>
>>> Hans, in your preferred approach you referred to "a format that is 
>>> as if it is a subdirectory of the masked executable." Did you have
>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>> when exec() loads the exe, and if this exists then the files rooted 
>>> in this directory would be set as the process's root filesystem?
>>>
>>> Are masks capable of explicit exclusion as well as inclusion?
>>> If the answer is 'Yes,' then what are your thoughts as to how this 
>>> might be accommodated when your main tool is reiser4's semantic tree 
>>> layer? Inclusion would be straightforward -- if the directory exists 
>>> or the name exists within the directory then fall through. But 
>>> exclusion? If you are limited to the semantic layer, then there's no 
>>> stat node with which to play tricks. 
>>
>> I think the correct answer is "anything not explicitly included is 
>> excluded"
>> or on the other side of the looking glass "anything not explicitly 
>> excluded
>> is included".
>>
>> As a user friendly interface both should be supported and the 
>> "compilation"
>> layer handle the conversion.
>>
>> Maybe I am not understanding the question.
>
>
> clearcase has an exclude operation for its view specifications.
>
I don't remember it being more than the boolean complement of
a (potentially much more complex) include operation.

So good UI point but I don't think extends the semantics?

>>> I wonder if it would be feasible if masks only specified exclusions? 
>>> If, for instance, the mask wanted to exclude /foo/*, then the 
>>> directory foo would exist (in the mask semantic tree). To exclude 
>>> /etc/passwd, passwd would exist in the directory /etc. Since you're 
>>> already going to need to preempt dcache searches (aren't you?) you 
>>> can insert a search of the mask tree. If the search fails, then it 
>>> is not excluded and the request falls through to normal VFS 
>>> handling. In the /etc/passwd case above, it would find /etc/passwd 
>>> and so the file is excluded. Processing would stop there, returning 
>>> some error. How does this sound? I need to sleep on this, because it 
>>> is very late here.
>>>  
>>>
>> At this time I think feasible is true and useful is an open question.
>>
>> To address the useful I find that known/desirable use-case scenarios
>> get the most discussion.
>>
>> To give a couple of examples:
>>     1) A given process (say a restricted shell) can not exec() an
>>         executable with the set-uid bit on.
>>          - directly
>>          - indirectly (e.g., via bash)
>>     2) Apache can only create/write files in /var/web/incoming.
>>          - files created or modified can not have any execute bit set 
>> and executing chmod is excluded.
>
>
> this protection happens while traversing the mask or at the fall 
> through point.  Hmmm, we need to accumulate a set of permissions that 
> apply to something that are specific to how we got there.  That could 
> be complex in the VFS details.  We can defer it to Phase II if 
> necessary.  George, you should spend a day (not this week) figuring 
> out how much work it would be to make that work.  It will be the 
> details of it that will be dangerous....
>
OK.

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>> George Beshers wrote:
>>
>>>
>>> David Dabbs wrote:
>>>
>>>> In the original proposal posted to the list Hans (I think) referred 
>>>> to viewprinting as "chroot on steroids." Let's assume that the mask 
>>>> creation tools deliver on making viewprint creation and 
>>>> maintainance very easy/painless for admins. In what way will 
>>>> viewprinting be more secure than chroot?
>>>>  
>>>>
>>> Basically, chroot as I at least normally use it, has a lot of 
>>> baggage in terms of
>>> disk consumption that we are planning to avoid by creating a view 
>>> rather than
>>> a copy.
>>
>>
>>
>> Chroot lacks fall through points.
>
>
> Other than saving disk space is this important?

It is different.

>
> Are you thinking about multiple processes, with different views, but
> sharing a few "resources", i.e., files of one form or another as part of
> a long term vision?

Yes, but chroot can also do that.

>
>>
>>>
>>>> Hans, in your preferred approach you referred to "a format that is 
>>>> as if it is a subdirectory of the masked executable." Did you have
>>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>>> when exec() loads the exe, and if this exists then the files rooted 
>>>> in this directory would be set as the process's root filesystem?
>>>>
>>>> Are masks capable of explicit exclusion as well as inclusion?
>>>> If the answer is 'Yes,' then what are your thoughts as to how this 
>>>> might be accommodated when your main tool is reiser4's semantic 
>>>> tree layer? Inclusion would be straightforward -- if the directory 
>>>> exists or the name exists within the directory then fall through. 
>>>> But exclusion? If you are limited to the semantic layer, then 
>>>> there's no stat node with which to play tricks. 
>>>
>>>
>>> I think the correct answer is "anything not explicitly included is 
>>> excluded"
>>> or on the other side of the looking glass "anything not explicitly 
>>> excluded
>>> is included".
>>>
>>> As a user friendly interface both should be supported and the 
>>> "compilation"
>>> layer handle the conversion.
>>>
>>> Maybe I am not understanding the question.
>>
>>
>>
>> clearcase has an exclude operation for its view specifications.
>>
> I don't remember it being more than the boolean complement of
> a (potentially much more complex) include operation.
>
> So good UI point but I don't think extends the semantics?

exclude is a semantic feature.

>
>
>>>> I wonder if it would be feasible if masks only specified 
>>>> exclusions? If, for instance, the mask wanted to exclude /foo/*, 
>>>> then the directory foo would exist (in the mask semantic tree). To 
>>>> exclude /etc/passwd, passwd would exist in the directory /etc. 
>>>> Since you're already going to need to preempt dcache searches 
>>>> (aren't you?) you can insert a search of the mask tree. If the 
>>>> search fails, then it is not excluded and the request falls through 
>>>> to normal VFS handling. In the /etc/passwd case above, it would 
>>>> find /etc/passwd and so the file is excluded. Processing would stop 
>>>> there, returning some error. How does this sound? I need to sleep 
>>>> on this, because it is very late here.
>>>>  
>>>>
>>> At this time I think feasible is true and useful is an open question.
>>>
>>> To address the useful I find that known/desirable use-case scenarios
>>> get the most discussion.
>>>
>>> To give a couple of examples:
>>>     1) A given process (say a restricted shell) can not exec() an
>>>         executable with the set-uid bit on.
>>>          - directly
>>>          - indirectly (e.g., via bash)
>>>     2) Apache can only create/write files in /var/web/incoming.
>>>          - files created or modified can not have any execute bit 
>>> set and executing chmod is excluded.
>>
>>
>>
>> this protection happens while traversing the mask or at the fall 
>> through point.  Hmmm, we need to accumulate a set of permissions that 
>> apply to something that are specific to how we got there.  That could 
>> be complex in the VFS details.  We can defer it to Phase II if 
>> necessary.  George, you should spend a day (not this week) figuring 
>> out how much work it would be to make that work.  It will be the 
>> details of it that will be dangerous....
>>
> OK.
>
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> George Beshers wrote:
>
>>>
>>> Chroot lacks fall through points.
>>
>>
>>
>> Other than saving disk space is this important?
>
>
> It is different.

Sure.  I am trying to understand the advantages/disadvantages
of fall through points in your thinking.

>> Are you thinking about multiple processes, with different views, but
>> sharing a few "resources", i.e., files of one form or another as part of
>> a long term vision?
>
>
> Yes, but chroot can also do that.

Achieve it yes, document it in the specification no.

>>>>> Hans, in your preferred approach you referred to "a format that is 
>>>>> as if it is a subdirectory of the masked executable." Did you have
>>>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>>>> when exec() loads the exe, and if this exists then the files 
>>>>> rooted in this directory would be set as the process's root 
>>>>> filesystem?
>>>>>
>>>>> Are masks capable of explicit exclusion as well as inclusion?
>>>>> If the answer is 'Yes,' then what are your thoughts as to how this 
>>>>> might be accommodated when your main tool is reiser4's semantic 
>>>>> tree layer? Inclusion would be straightforward -- if the directory 
>>>>> exists or the name exists within the directory then fall through. 
>>>>> But exclusion? If you are limited to the semantic layer, then 
>>>>> there's no stat node with which to play tricks. 
>>>>
>>>>
>>>>
>>>> I think the correct answer is "anything not explicitly included is 
>>>> excluded"
>>>> or on the other side of the looking glass "anything not explicitly 
>>>> excluded
>>>> is included".
>>>>
>>>> As a user friendly interface both should be supported and the 
>>>> "compilation"
>>>> layer handle the conversion.
>>>>
>>>> Maybe I am not understanding the question.
>>>
>>>
>>>
>>>
>>> clearcase has an exclude operation for its view specifications.
>>>
>> I don't remember it being more than the boolean complement of
>> a (potentially much more complex) include operation.
>>
>> So good UI point but I don't think extends the semantics?
>
>
> exclude is a semantic feature.

Can you elaborate please?  That is specifically why it is different
from "not included"?

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>> George Beshers wrote:
>>
>>>>
>>>> Chroot lacks fall through points.
>>>
>>>
>>>
>>>
>>> Other than saving disk space is this important?
>>
>>
>>
>> It is different.
>
>
> Sure.  I am trying to understand the advantages/disadvantages
> of fall through points in your thinking.
>
>>> Are you thinking about multiple processes, with different views, but
>>> sharing a few "resources", i.e., files of one form or another as 
>>> part of
>>> a long term vision?
>>
>>
>>
>> Yes, but chroot can also do that.
>
>
> Achieve it yes, document it in the specification no.

I don't understand the difference between us doing ls -R in a view and 
in a chrooted root, as far as documentation is concerned.

What might be different is that two processes can share a common 
directory (that they can create files in for the other process to see) 
using a mask but not using chroot.  Am I right about that?

>
>>>>>> Hans, in your preferred approach you referred to "a format that 
>>>>>> is as if it is a subdirectory of the masked executable." Did you 
>>>>>> have
>>>>>> in mind checking for something like 
>>>>>> /usr/bin/fooprocess/metas/mask when exec() loads the exe, and if 
>>>>>> this exists then the files rooted in this directory would be set 
>>>>>> as the process's root filesystem?
>>>>>>
>>>>>> Are masks capable of explicit exclusion as well as inclusion?
>>>>>> If the answer is 'Yes,' then what are your thoughts as to how 
>>>>>> this might be accommodated when your main tool is reiser4's 
>>>>>> semantic tree layer? Inclusion would be straightforward -- if the 
>>>>>> directory exists or the name exists within the directory then 
>>>>>> fall through. But exclusion? If you are limited to the semantic 
>>>>>> layer, then there's no stat node with which to play tricks. 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think the correct answer is "anything not explicitly included is 
>>>>> excluded"
>>>>> or on the other side of the looking glass "anything not explicitly 
>>>>> excluded
>>>>> is included".
>>>>>
>>>>> As a user friendly interface both should be supported and the 
>>>>> "compilation"
>>>>> layer handle the conversion.
>>>>>
>>>>> Maybe I am not understanding the question.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> clearcase has an exclude operation for its view specifications.
>>>>
>>> I don't remember it being more than the boolean complement of
>>> a (potentially much more complex) include operation.
>>>
>>> So good UI point but I don't think extends the semantics?
>>
>>
>>
>> exclude is a semantic feature.
>
>
> Can you elaborate please?  That is specifically why it is different
> from "not included"?

Not included is also a semantic feature.  Explicit rather than implicit 
exclusion is a different semantic.  Lingustic expressions can differ in 
their semantics while still  resolving to the same value.

If A = 1 and B =1 and C = 2

then A + B + C is semantically different from 2 * C, even if it is 
numerically equal.

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> George Beshers wrote:
>
>>
>>
>>
>>
>> Sure.  I am trying to understand the advantages/disadvantages
>> of fall through points in your thinking.
>>
>>>> Are you thinking about multiple processes, with different views, but
>>>> sharing a few "resources", i.e., files of one form or another as 
>>>> part of
>>>> a long term vision?
>>>
>>>
>>>
>>>
>>> Yes, but chroot can also do that.
>>
>>
>>
>> Achieve it yes, document it in the specification no.
>
>
> I don't understand the difference between us doing ls -R in a view and 
> in a chrooted root, as far as documentation is concerned.
>
> What might be different is that two processes can share a common 
> directory (that they can create files in for the other process to see) 
> using a mask but not using chroot.  Am I right about that?

Unsure.  I will try nested chroot tomorrow.  What I do know is that 
files written by a chroot process
can be seen by a non-chroot process.  What I find attractive in the mask 
specification is that one
could understand that, e.g., lp was putting files in the spooling area 
and lpd or cupsd was actually
reading them and removing them.

Grant you it is beyond the current project, but would be nice to be able 
to isolate all the programs
with rights to manipulate files in /var/whatever or /etc/whatever.

>>>> I don't remember it being more than the boolean complement of
>>>> a (potentially much more complex) include operation.
>>>>
>>>> So good UI point but I don't think extends the semantics?
>>>
>>>
>>>
>>>
>>> exclude is a semantic feature.
>>
>>
>>
>> Can you elaborate please?  That is specifically why it is different
>> from "not included"?
>
>
> Not included is also a semantic feature.  Explicit rather than 
> implicit exclusion is a different semantic.  Lingustic expressions can 
> differ in their semantics while still  resolving to the same value.
>
> If A = 1 and B =1 and C = 2
>
> then A + B + C is semantically different from 2 * C, even if it is 
> numerically equal.
>
Ah... my language design background gets us into communication trouble :-)

Suppose for a moment that exclude actually added functionality (as for 
example
regular expressions over file names will) what terminology would you use?
You see, to me the exclude is, at some level, little more than syntactic 
sugar
for the specification tools because the expressive power is equivalent 
in theory
even if using exclusion is much more convenient in practice.

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
> Ah... my language design background gets us into communication trouble 
> :-)
>
> Suppose for a moment that exclude actually added functionality (as for 
> example
> regular expressions over file names will) what terminology would you use?
> You see, to me the exclude is, at some level, little more than 
> syntactic sugar
> for the specification tools because the expressive power is equivalent 
> in theory
> even if using exclusion is much more convenient in practice.

Do you consider the various turing complete languages to have 
significant semantic differences?

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]



Hans Reiser wrote:

> George Beshers wrote:
>
>>
>> Ah... my language design background gets us into communication 
>> trouble :-)
>>
>> Suppose for a moment that exclude actually added functionality (as 
>> for example
>> regular expressions over file names will) what terminology would you 
>> use?
>> You see, to me the exclude is, at some level, little more than 
>> syntactic sugar
>> for the specification tools because the expressive power is 
>> equivalent in theory
>> even if using exclusion is much more convenient in practice.
>
>
> Do you consider the various turing complete languages to have 
> significant semantic differences?

Yes, but I understand your point.

The distinction I am drawing is that something is syntactic sugar if 
there is an
algorithm to translate some syntactic construct into a subset of a language
with more primitive attributes, e.g., 'elseif' is syntactic sugar.

Assume the alphabet is lower case letters for simplicity.

    exclude "bar"

becomes

    include ".|..|[ac-z][b-z][a-qs-z]|...+"

A moments thought and you will see that both can be implemented with
5 state finite state autometa (adding a failure/success state as the 5th 
state
with entire alphabet transitioning to the 5th state).

I completely agree that the exclude clause is much cleaner syntactically
and the specification compiler should handle them (requirement), but
I don't think they are a consideration in terms of the "compiled" spec
that must be evaluated in the kernel as the process is being run.

*Getting Pragmatic
*
I have been assuming a model something like the following:

 -  There is a *presentation mask* format (the mask source) that is
     platform independent and probably human readable.

 -  There is a *compiled mask* which is designed to optimize *mask
     evaluation*, i.e., the chroot like semantics.

 -  The mask evaluation is done by the *mask interpreter* which is
    in the kernel (reiser4 area until we take over the world ;-) ).

 -  That the format produced by tracing can be converted to a
    presentation mask for user editing.

Proposed definition:

    An extension to the presentation mask language is *syntactic sugar*
    Iff it does not require increasing the complexity of the mask 
interpreter.


[-- Attachment #2: Type: text/html, Size: 3081 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>     include ".|..|[ac-z][b-z][a-qs-z]|...+"
>
> A moments thought and you will see that both can be implemented with
> 5 state finite state autometa (adding a failure/success state as the 
> 5th state
> with entire alphabet transitioning to the 5th state).

Yes, but you can avoid the transformation and just have a mask that 
excludes what it lists.  You can have bounce off points instead of fall 
through points.

You can also have the exclude be a completely separate mask from the 
include mask.

It is an interesting question whether that is a good or a bad idea....  
it might be a good idea but less space efficient.

>
> I completely agree that the exclude clause is much cleaner syntactically
> and the specification compiler should handle them (requirement), but
> I don't think they are a consideration in terms of the "compiled" spec
> that must be evaluated in the kernel as the process is being run.
>
> *Getting Pragmatic
> *
> I have been assuming a model something like the following:
>
>  -  There is a *presentation mask* format (the mask source) that is
>      platform independent and probably human readable.

Nah, I no longer think so, I like

ls -R executable/metas/mask

as what the humans look at.

>
>  -  There is a *compiled mask* which is designed to optimize *mask
>      evaluation*, i.e., the chroot like semantics.
>
>  -  The mask evaluation is done by the *mask interpreter* which is
>     in the kernel (reiser4 area until we take over the world ;-) ).
>
>  -  That the format produced by tracing can be converted to a
>     presentation mask for user editing.

Just use the filesystem tree and create a few fall through and bounce 
off plugins.

>
> Proposed definition:
>
>     An extension to the presentation mask language is *syntactic sugar*
>     Iff it does not require increasing the complexity of the mask 
> interpreter.
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Ah, I suspect that this disagreement has more to do with:

    What should go into the proof of concept implementation?

vs.

    What is needed to win Linux community support?

Hans Reiser wrote:

> George Beshers wrote:
>
>>
>>     include ".|..|[ac-z][b-z][a-qs-z]|...+"
>>
>> A moments thought and you will see that both can be implemented with
>> 5 state finite state autometa (adding a failure/success state as the 
>> 5th state
>> with entire alphabet transitioning to the 5th state).
>
>
> Yes, but you can avoid the transformation and just have a mask that 
> excludes what it lists.  You can have bounce off points instead of 
> fall through points.

True.

> You can also have the exclude be a completely separate mask from the 
> include mask.

True.

> It is an interesting question whether that is a good or a bad 
> idea....  it might be a good idea but less space efficient.

Also potentially a greater performance hit.

>> I completely agree that the exclude clause is much cleaner syntactically
>> and the specification compiler should handle them (requirement), but
>> I don't think they are a consideration in terms of the "compiled" spec
>> that must be evaluated in the kernel as the process is being run.
>>
>> *Getting Pragmatic
>> *
>> I have been assuming a model something like the following:
>>
>>  -  There is a *presentation mask* format (the mask source) that is
>>      platform independent and probably human readable.
>
>
> Nah, I no longer think so, I like
>
> ls -R executable/metas/mask
>
> as what the humans look at.

To gain community support we are going to need a way to ship
the masks with the executables, and probably parameterize them
for Makefiles.  Grant you it is Phase II work, but it will become a
requirement.

>
>>
>>  -  There is a *compiled mask* which is designed to optimize *mask
>>      evaluation*, i.e., the chroot like semantics.
>>
>>  -  The mask evaluation is done by the *mask interpreter* which is
>>     in the kernel (reiser4 area until we take over the world ;-) ).
>>
>>  -  That the format produced by tracing can be converted to a
>>     presentation mask for user editing.
>
>
> Just use the filesystem tree and create a few fall through and bounce 
> off plugins.

For the proof of concept I agree.

Hans, while your points are valid, they are not compelling.  The 
transformations involved
have been well understood for 3-4 decades. 

Ultimately, performance and scalability needs to drive these 
implementation/optimization
decisions and they can and should wait until we have something working 
and can take
measurements.

> Proposed definition:
>
>>
>>     An extension to the presentation mask language is *syntactic sugar*
>>     Iff it does not require increasing the complexity of the mask 
>> interpreter.
>>
>
>

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
> Ah, I suspect that this disagreement has more to do with:
>
>    What should go into the proof of concept implementation?
>
> vs.
>
>    What is needed to win Linux community support?
>
> Hans Reiser wrote:
>
>> George Beshers wrote:
>>
>>>
>>>     include ".|..|[ac-z][b-z][a-qs-z]|...+"
>>>
>>> A moments thought and you will see that both can be implemented with
>>> 5 state finite state autometa (adding a failure/success state as the 
>>> 5th state
>>> with entire alphabet transitioning to the 5th state).
>>
>>
>>
>> Yes, but you can avoid the transformation and just have a mask that 
>> excludes what it lists.  You can have bounce off points instead of 
>> fall through points.
>
>
> True.
>
>> You can also have the exclude be a completely separate mask from the 
>> include mask.
>
>
> True.
>
>> It is an interesting question whether that is a good or a bad 
>> idea....  it might be a good idea but less space efficient.
>
>
> Also potentially a greater performance hit.
>
>>> I completely agree that the exclude clause is much cleaner 
>>> syntactically
>>> and the specification compiler should handle them (requirement), but
>>> I don't think they are a consideration in terms of the "compiled" spec
>>> that must be evaluated in the kernel as the process is being run.
>>>
>>> *Getting Pragmatic
>>> *
>>> I have been assuming a model something like the following:
>>>
>>>  -  There is a *presentation mask* format (the mask source) that is
>>>      platform independent and probably human readable.
>>
>>
>>
>> Nah, I no longer think so, I like
>>
>> ls -R executable/metas/mask
>>
>> as what the humans look at.
>
>
> To gain community support we are going to need a way to ship
> the masks with the executables, and probably parameterize them
> for Makefiles.  Grant you it is Phase II work, but it will become a
> requirement.

True.  We need to modify tar I think.

>
>>
>>>
>>>  -  There is a *compiled mask* which is designed to optimize *mask
>>>      evaluation*, i.e., the chroot like semantics.
>>>
>>>  -  The mask evaluation is done by the *mask interpreter* which is
>>>     in the kernel (reiser4 area until we take over the world ;-) ).
>>>
>>>  -  That the format produced by tracing can be converted to a
>>>     presentation mask for user editing.
>>
>>
>>
>> Just use the filesystem tree and create a few fall through and bounce 
>> off plugins.
>
>
> For the proof of concept I agree.

and for the non-proof of concept you would do what?

>
> Hans, while your points are valid, they are not compelling.  The 
> transformations involved
> have been well understood for 3-4 decades.
> Ultimately, performance and scalability needs to drive these 
> implementation/optimization
> decisions and they can and should wait until we have something working 
> and can take
> measurements.
>
>> Proposed definition:
>>
>>>
>>>     An extension to the presentation mask language is *syntactic sugar*
>>>     Iff it does not require increasing the complexity of the mask 
>>> interpreter.
>>>
>>
>>
>
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]



Hans Reiser wrote:

> George Beshers wrote:
>
>>  -  There is a *compiled mask* which is designed to optimize *mask
>>
>>>      evaluation*, i.e., the chroot like semantics.
>>>
>>>  -  The mask evaluation is done by the *mask interpreter* which is
>>>     in the kernel (reiser4 area until we take over the world ;-) ).
>>>
>>>  -  That the format produced by tracing can be converted to a
>>>     presentation mask for user editing.
>>
>>
>>
>>
>> Just use the filesystem tree and create a few fall through and bounce 
>> off plugins.
>
>>
>>
>> For the proof of concept I agree.
>
>
> and for the non-proof of concept you would do what?
>
It depends on how useful people find the masks and what extensions 
people start
asking for.

I think mask composition (because of inheritance, group specific access 
rights,
whatever) is likely to be an emerging requirement.  Merging several masks
into a single mask would then be a form of optimization.

I also think that combining masks with other aspects of SELinux, as was 
suggested
in an earlier e-mail, is a potentially quite fruitful phase II scenario.

Another possibility is that simple paths will prove not to be 
sufficient, people
will want/need path patterns.  For example, each user is allowed their own
~user/bin and ~user/lib  and those programs can load .so's from trusted 
libraries
but not from ~user2/lib (for whatever reason).  The point is that in 
this case
is that a common substring is required.

So, for the time being, I will note that trees *are* a really good 
implementation
strategy for the masks that can be specified in my proof of concept proposal
and will wait for a compelling example to justify returning to full REs over
paths or promoting the utility of composition of masks.

Besides, I recently received saga advice about the dangers of "analysis 
paralysis"

    George, trust me, the project will be a LOT more fun if we implement
    the bare minimum
    and get it done early, and then after that spend the rest of the
    time doing what amuses us.

;-)

>>
>> Hans, while your points are valid, they are not compelling.  The 
>> transformations involved
>> have been well understood for 3-4 decades.
>> Ultimately, performance and scalability needs to drive these 
>> implementation/optimization
>> decisions and they can and should wait until we have something 
>> working and can take
>> measurements.
>>
>>> Proposed definition:
>>>
>>>>
>>>>     An extension to the presentation mask language is *syntactic 
>>>> sugar*
>>>>     Iff it does not require increasing the complexity of the mask 
>>>> interpreter.
>>>>
>>>
>>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3792 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

David Dabbs wrote:

>Hans and George,
>
>I've been lurking at the edge of this discussion and have not chimed in 
>mostly because I only have a dial-up connection here at my in-laws
>house (and I'm suposed to be on vacation). Since there was a request for 
>arguments for or against Hans's preferred approach, I thought I'd add 
>my $0.02.
>
>In order to put everything into perspective as well as to provide context
>for some questions, I attempted to distill concrete items or decisions from 
>the last several days' exchanges.
>
>As to arguments For or Against; 
>For
>If you only have three months to prove a concept and obtain continued 
>funding, then I agree with Hans's preference for reusing as much 
>existing work as possible. Adapting Hans's statement regarding 
>[in]compatibility, "...if we [write new code] we should do 
>so only if it is sufficiently worthwhile." 
>
>Against
>I can think of none at this point, given my understanding of 
>the features. 
>
>
>Project
>----------------------------------------------------------------------
>Demonstrate process-oriented filesystem viewprinting that scales to 
>filesystems (and masks) containing millions of files. Provide 
>exec-time mask application as well as tools for automating mask 
>creation and maintenance.
>
>
>Definitions
>---------------------------------------------------------------------
>Process-Oriented
>Specifications of filesystem object visibility are applied to processes 
>regardless of the effective user rights with which the process runs.
>
>Mask (or viewprint)
>A specification as to which files are visible to process[es] 
>"running under" the mask. The [file] security underlying the mask
>remains a user/object/permission mapping. If a mask a) does not 
>include a file or b) explicitly filters out acess, the file operation ceases
>and an error is returned. If the file upon which the process wants to 
>operate is not filtered by the mask, then the operation request is 
>passed on to the underlying filesystem. There, the requested file 
>a) might not exist, b) might exist but not be visible/readable by the 
>user running the process, etc. 
>
>Fall-Through Point
>The point during some file operation at which it is determined that the 
>file is not filtered by the mask. The request [for operation X on the file]
>is passed on to the VFS/underlying filesystem. 
>
>
>
>Features & Performance (Qualitative/Soft)
>----------------------------------------------------------------------
>It is...our task to ensure that creating a correct mask is well automated 
>and easy.
>
>We do process oriented security, and that is all for now. The underlying 
>[file] security remains a user/object/permission mapping.
>
>We need to be able to determine in insignificant time whether a file 
>"passes through" a mask consisting of a million filenames.
>
>..if we must break an existing program we should do so only with care 
>and only if it is sufficiently worthwhile to do so. 
>
>
>Features & Performance (Quantitative/Hard)
>----------------------------------------------------------------------
>Masks 
>- must support dirname/* 
>- do not [yet] need to support dirname/foo.*
>- should not allow symbolic link traversal unless the file pointed to 
>   is within the mask.
>  
>

>- (by extension) should not allow hard links unless the file 
>  pointed to is within the mask.
>  
>
^ should not allow hard links^ should not allow hard link to be created.

>
>
>Hans's Initial Considerations & Design Proposal
>----------------------------------------------------------------------
>[The solution] must be treelike in its performance scalability.
>
>It is very important that we have something simple that reuses code for 
>this purpose. The big issue to decide at the start is, should a view 
>specification be implemented with a format that is as if it is a 
>subdirectory of the masked executable, and which we then take the 
>filenames used by the executable and traverse the subdirectory as 
>though it was root, and if we reach a valid fall through point, then 
>allow [us to] traverse from the real filesystem root, and if not, 
>we issue a suitable error.
>
>This would let us use all the existing semantic tree traversal code.
>It would, however, require us to add such plugins as "fall through points", 
>and "prints", etc.  I think the answer is yes, we want to do it this way.  
>Please come up with arguments for and against it.
>
>
>
>Questions
>----------------------------------------------------------------------
>Handwaving for a moment over view creation and storage particulars, it
>is pretty clear that this new security feature will rely upon reiser4 
>for masking. Does this mean that one will only be able to mask a 
>reiser4 filesystem
>
yes

>, or will any VFS fs be "maskable?"
>  
>
Filesystems without support for plugins are a horror....;-)

The other filesystems will be encouraged to adopt the reiser4 plugin 
infrastructure.....

>All file types and access methods will be supported, yes? 
>(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)
>  
>
Yes.

>In the original proposal posted to the list Hans (I think) referred to 
>viewprinting as "chroot on steroids." Let's assume that the mask 
>creation tools deliver on making viewprint creation and maintainance 
>very easy/painless for admins. In what way will viewprinting be more 
>secure than chroot? 
>  
>
It won't.  Security research is the art of security/effort.  Maximizing 
just security is a solved problem, and is called a turned off computer 
in a good safe.

Viewprinting is less work than chroot.

>If I understand the ways admins use chroot, or would like to use it, 
>then should the design include "stackable" or "inheritable" masks? 
>  
>
Sure, but not in 1.0.  Good point though.

>This is not unlike stackable filesystems or filter pipelines. If, 
>for instance, most processes need to see /usr/local/lib/* and 
>/usr/local/bin/*, then this spec is in a 'base' mask and the mask 
>for /usr/local/bin/fooprocess would inhert from and add to this 
>base specification.
>  
>
I dislike your example but agree with your argument.

>Early on in the conversation, there was discussion about 
>"permissible functionality." At a minimum, a mask, true to its name, 
>will effect filesystem object _visibility_. It was not completely 
>clear whether the mask will be proscriptive viz operations. IOW, will 
>the mask say that fooprocess "is not permitted to [attempt to] RWX 
>object bar?" I believe this is not something masks will do, but I 
>wanted clarification.
>  
>
I don't know why I don't understand your question, but I don't.....;-)

>Hans, in your preferred approach you referred to "a format that 
>is as if it is a subdirectory of the masked executable." Did you have
>in mind checking for something like /usr/bin/fooprocess/metas/mask 
>when exec() loads the exe,
>
yes

> and if this exists then the files rooted 
>in this directory would be set as the process's root filesystem?
>  
>
your statement is imprecise.

The mask will be checked first, and then iff it falls through we do a 
normal filesystem traversal.

>Are masks capable of explicit exclusion as well as inclusion?
>  
>
Not in version 1.0.

>If the answer is 'Yes,' then what are your thoughts as to how this 
>might be accommodated when your main tool is reiser4's semantic 
>tree layer? Inclusion would be straightforward -- if the directory 
>exists or the name exists within the directory then fall through. 
>But exclusion?
>
True, it might be an issue.  I must think about it.

> If you are limited to the semantic layer, then there's 
>no stat node with which to play tricks. 
>
>I wonder if it would be feasible if masks only specified 
>exclusions? If, for instance, the mask wanted to exclude /foo/*, 
>then the directory foo would exist (in the mask semantic tree). 
>To exclude /etc/passwd, passwd would exist in the directory /etc. 
>Since you're already going to need to preempt dcache searches 
>(aren't you?)
>
Sigh, yes, or we need to use dcache for the mask.

> you can insert a search of the mask tree. If the 
>search fails, then it is not excluded and the request falls through 
>to normal VFS handling. In the /etc/passwd case above, it would find 
>/etc/passwd and so the file is excluded. Processing would stop there, returning some error. How does this sound? I need to sleep on this, 
>because it is very late here.
>  
>
I don't quite understand this paragraph above.

>
>David
>
>
>  
>

Re: viewprinting: what format should views be stored in?

[David Dabbs]

Motivation
----------------------------------------------------------------------
See Hans's original post. In and of itself, viewprinting will not be 
more secure than chroot. Viewprinting should be less work than 
chroot. By virtue of its being easier to deploy and administer, the 
net effect should be increased security, assuming more admins deploy
viewprinting.


Later Phase Considerations
----------------------------------------------------------------------
- Explicit exclusion in masks. 
- Notions of mask inheritance


Definitions
---------------------------------------------------------------------
Process-Oriented
Specifications of filesystem object visibility are applied to processes 
regardless of the effective user rights with which the process runs.

Mask (or viewprint)
A specification as to which files are visible to process[es] 
"running under" the mask. The [file] security underlying the mask
remains a user/object/permission mapping applied by the underlying
filesystem. If a mask a) does not include a file or b) explicitly 
filters out acess, the file operation ceases and an error is returned. 
If the file upon which the process wants to operate is not filtered by 
the mask, then the operation request is passed on to the underlying 
filesystem. There, the requested file a) might not exist, b) might 
exist but not be visible/readable by the user running the process, etc. 
 
Fall-Through Point
The point during some file operation at which it is determined that the 
file is not filtered by the mask. The request [for operation X on the file]
is passed on to the VFS/underlying filesystem. 



Features & Constraints
----------------------------------------------------------------------
Masks 
- must support dirname/* 
- do not [yet] need to support dirname/foo.*
- should not allow symbolic link traversal unless the file pointed to 
  is within the mask.

Masked Processes
- May not create hard links.
- Child processes [of a masked process] must inherit the parent's 
  "mask bit" and mask definition.

Filesystem Support
- Reiser4 fs code will be required to implement viewprinting.
- Only Reiser4 filesystems may be "masked."

 

Questions
----------------------------------------------------------------------
>All file types and access methods will be supported, yes? 
>(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)
>
>Hans: Yes.
>...except that they cannot create hard links (above)

Is this restriction unequivocal (yes)? 
Any other forbidden Unix fs objects or fs operations?


> Early on in the conversation, there was discussion about 
> "permissible functionality." At a minimum, a mask, true to its name, 
> will effect filesystem object _visibility_. It was not completely 
> clear whether the mask will be proscriptive viz operations. IOW, will 
> the mask say that fooprocess "is not permitted to [attempt to] RWX 
> object bar?" I believe this is not something masks will do, but I 
> wanted clarification.
> 
> 
>I don't know why I don't understand your question, but I don't.....;-)


Let me try again. At a mininmum, a mask specifies what objects are
visible to a process, correct? If objext X is included in or not 
explicitly excluded from the mask, then fooprocess is allowed to 
_attempt_to_ operate on object X. I say "attempt to" because, at 
that point (fall-through), the mask is finished wrt the operation, 
yes? Permission to actually carry out an operation on object X is 
determined by the user/object/permission mapping in the underlying
filesystem.

What was not clear to me was whether masks specified, proscribed, or
in any way controlled filesystem operations (permissions) for objects
that are visible when running under the mask. If so, what can be 
specified and is it an "allow" a "deny" or either?


> Hans, in your preferred approach you referred to "a format that 
> is as if it is a subdirectory of the masked executable." Did you have
> in mind checking for something like /usr/bin/fooprocess/metas/mask 
> when exec() loads the exe,
> 
> yes
>
> and if this exists then the files rooted in this directory 
> would be set as the process's root filesystem?
> 
>Your statement is imprecise. The mask will be checked first, and 
>then iff it falls through we do a normal filesystem traversal.

It was imprecise because perhaps I had a different vprint concept 
and implementation in mind. Using the creation tool, JAdmin creates 
a mask for fooprocess. The mask would be a directory structure 
rooted at /bin/fooprocess/metas/mask. All files (not dirs) in 
this tree would be hard links to the "real" files specified in the mask. 
Only dirs & files included in the spec are visible. When an instance of 
fooprocess is started, /bin/fooprocess/metas/mask is automagically mounted 
as the process's root filesystem. The mask would be the filesystem. 
Other than the use of the metas reiserism (and mask maintenance wizardry)
this is not any different than chroot. Since the end result here is
to be no more secure than chroot, but very much easier to deploy and 
maintain, is there a reason why this cannot be the case?


> If you are limited to the semantic layer, then there's 
> no stat node with which to play tricks. 
> 
> I wonder if it would be feasible if masks only specified 
> exclusions? If, for instance, the mask wanted to exclude /foo/*, 
> then the directory foo would exist (in the mask semantic tree). 
> To exclude /etc/passwd, passwd would exist in the directory /etc. 
> Since you're already going to need to preempt dcache searches 
> (aren't you?)
> 
>Sigh, yes, or we need to use dcache for the mask.

> you can insert a search of the mask tree. If the 
> search fails, then it is not excluded and the request falls through 
> to normal VFS handling. In the /etc/passwd case above, it would find 
> /etc/passwd and so the file is excluded. Processing would stop there, 
> returning some error. How does this sound? 
> 
>I don't quite understand this paragraph above.


Probably because I'm not on the same page as you and George.
Imagine a filesystem with two trees: one, the real
root filesystem and two, the anti-root tree (exclusions). This
fs would be the root fs for the process. Let's say fooprocess has 
the following exclusions:

	/etc/passwd
	/etc/shadow
	/var

Above, when I said "insert a search of the mask tree" what I meant was
"first search the exception [semantic] tree (anti-tree) associated with 
this process. If you find the object there, then report it as NOT FOUND.
Otherwise, proceed with a normal fs tree search (fall-through). Basically,
a dynamic, per-process (er, per mask) hidden attribute. The modified VFS 
code to store the dentry of the root of the mask base dir, then use 
normal namei(), etc. path resolution interfaces to see if the file exists 
in the exception list? IOW, when fooprocess attempts to open /etc/passwd 
when fooprocess is under the above mask, the following happens: VFS 
identifies process as being undermask and so knows dentry of the base dir 
of the exception list (fooprocess/metas/mask). Before doing 'normal' 
handling, VFS treats this as a request to operate on 
fooprocess/metas/mask/etc/passwd. If VFS finds the filename, then NOT 
FOUND is returned. Otherwise, file processing proceeds normally.

> George:
> To give a couple of examples:
>     1) A given process (say a restricted shell) can not exec() an
>         executable with the set-uid bit on.
>          - directly
>          - indirectly (e.g., via bash)
>     2) Apache can only create/write files in /var/web/incoming.
>          - files created or modified can not have any execute bit set 
> and executing chmod is excluded.
>
>Hans:
>this protection happens while traversing the mask or at the fall through 
>point.  Hmmm, we need to accumulate a set of permissions that apply to 
>something that are specific to how we got there.  That could be complex 
>in the VFS details.  We can defer it to Phase II if necessary.  George, 
>you should spend a day (not this week) figuring out how much work it 
>would be to make that work.  It will be the details of it that will be 
>dangerous....

I'll tackle scenario #2:
* Executing chmod would be excluded because it would not be visible in the mask.
* "files created or modified can not have any execute bit set" 
  Implicit in this statement is that, in addition to filtering object 
  visibility, masks will preempt/proscribe certain fs operations -- in this 
  case, the setting of certain attributes (i.e. exec bit). If this is correct
  then what can masks allow/prohibit WRT operations/attributes performed
  on objects. This is what I was trying to clarify with my earlier question.


David

Re: viewprinting: what format should views be stored in?

[David Greaves]

Hi

I've been following and have an interest - I hope my comments and 
observations are valuable.

First, allow me to suggest some more terminology - like George, I always 
like to see this done early :)
Masklet : set of modifications to a filename's access authorisations
Mask: collection of Masklets (possibly only 1)

Most of the time one will use 'mask'; eg one can now traverse a mask (cf 
an image overlay) however one can use masklet to refer to a specific 
instance (a complex mask pixel)
I've used this terminology below and I think it's OK.

David Dabbs wrote:

>Fall-Through Point
>The point during some file operation at which it is determined that the 
>file is not filtered by the mask. The request [for operation X on the file]
>is passed on to the VFS/underlying filesystem. 
>  
>
This doesn't sound right.
(Basically I suspect there has been confusion over 'visibilty' and file 
attribute masking)

When did masks specify visibility of files? According to Hans :

> Hmm.  Yes, views should allow masking permissions.

mind you, he then said:

> We need to be able to support specifying a mask that allows any file 
> within a given directory to be visible.  That is, we need to support 
> dirname/* but we don't yet need to support dirname/foo.* 

I think (see last paragraphs of this email) that we have a collection of 
masklet types.

>
>
>Features & Constraints
>----------------------------------------------------------------------
>Masks 
>- must support dirname/* 
>- do not [yet] need to support dirname/foo.*
>- should not allow symbolic link traversal unless the file pointed to 
>  is within the mask.
>  
>
simple question here:
does dirname/* go deep into the directory tree??

It doesn't in shell syntax

Maybe dirname/**
(which means the complete tree below dirname)

Important I think.
Also introduces the question of 'rule' interaction

dirname/bar/foo : maska
dirname/bar/*     : maskb
dirname**           : mask c

which mask?
options:
 AND?
 most specific? (definition)
 first to match?


>Masked Processes
>- May not create hard links.
>- Child processes [of a masked process] must inherit the parent's 
>  "mask bit" and mask definition.
>  
>
remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? filesystem?
Hans actually says it's derived from the executable.
What if it changes between two processes starting?
Does the running processes mask change? (cf chmod a file - seems 
reasonable but...)
I'd think it needs to be pretty atomic...
In fact, maybe changing masks on a running (mounted?) system is a 
potential security hole and forbidden?
I think I could think of race examples.

aside: talking about reuse, maybe the recent lkml JOB patch is useful:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109278360210574&w=2

+       A job is a group of related processes all descended from a
+       point of entry process and  identified  by  a  unique  job
+       identifier  (jid).   A  job  can	 contain multiple process
+       groups or sessions, and all processes in one of these sub-
+       groups can only be contained within a single job.
+
+       The  primary  purpose  for  having  jobs is to provide job
+       based resource limits.

Maybe exe's can have something _like_ setuid? setmid()?
mid being based on jid?

>Questions
>----------------------------------------------------------------------
>  
>
>>All file types and access methods will be supported, yes? 
>>(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)
>>
>>Hans: Yes.
>>...except that they cannot create hard links (above)
>>    
>>
>
>Is this restriction unequivocal (yes)? 
>Any other forbidden Unix fs objects or fs operations?
>  
>
Obviously creating a hardlink _can_ circumvent semantically specified 
security.
But shouldn't that just be a masklet attribute? see below (end)

>>Early on in the conversation, there was discussion about 
>>"permissible functionality." At a minimum, a mask, true to its name, 
>>will effect filesystem object _visibility_. It was not completely 
>>clear whether the mask will be proscriptive viz operations. IOW, will 
>>the mask say that fooprocess "is not permitted to [attempt to] RWX 
>>object bar?" I believe this is not something masks will do, but I 
>>wanted clarification.
>>
>>
>>I don't know why I don't understand your question, but I don't.....;-)
>>    
>>
>
>
>Let me try again. At a mininmum, a mask specifies what objects are
>visible to a process, correct? If objext X is included in or not 
>explicitly excluded from the mask, then fooprocess is allowed to 
>_attempt_to_ operate on object X. I say "attempt to" because, at 
>that point (fall-through), the mask is finished wrt the operation, 
>yes? Permission to actually carry out an operation on object X is 
>determined by the user/object/permission mapping in the underlying
>filesystem.
>
>What was not clear to me was whether masks specified, proscribed, or
>in any way controlled filesystem operations (permissions) for objects
>that are visible when running under the mask. If so, what can be 
>specified and is it an "allow" a "deny" or either?
>  
>
So, you're saying that a mask can deny authorisation but not grant it.
(In which case 'mask' is a good word and the concept of AND goes into 
the foundations)

A process can read/write/execute according to FS permissions.
If the files 'acl/attr' doesn't allow writing then the mask _cannot_ 
override this and allow a masked process to write to the file.

This sounds sensible.

>>Hans, in your preferred approach you referred to "a format that 
>>is as if it is a subdirectory of the masked executable." Did you have
>>in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>when exec() loads the exe,
>>
>>yes
>>
>>and if this exists then the files rooted in this directory 
>>would be set as the process's root filesystem?
>>
>>Your statement is imprecise. The mask will be checked first, and 
>>then iff it falls through we do a normal filesystem traversal.
>>    
>>
>
>It was imprecise because perhaps I had a different vprint concept 
>and implementation in mind. Using the creation tool, JAdmin creates 
>a mask for fooprocess. The mask would be a directory structure 
>rooted at /bin/fooprocess/metas/mask. All files (not dirs) in 
>this tree would be hard links to the "real" files specified in the mask. 
>Only dirs & files included in the spec are visible. When an instance of 
>fooprocess is started, /bin/fooprocess/metas/mask is automagically mounted 
>as the process's root filesystem. The mask would be the filesystem. 
>Other than the use of the metas reiserism (and mask maintenance wizardry)
>this is not any different than chroot. Since the end result here is
>to be no more secure than chroot, but very much easier to deploy and 
>maintain, is there a reason why this cannot be the case?
>  
>
I think the 'thing' at /usr/bin/fooprocess/metas/mask
is a semantic expansion of the mask (ie it's like a directory tree but 
it doesn't point to files, it just contains lots of masklets).
It can be traversed in parallel to the real tree traversal and the 
masklets it returns will modify the real results. It is purely semantic. 
I've expanded this later.

Call it a maskfs?
The email subject becomes:
Re: viewprinting: what format should maskfs use?
The answer of course is something very similar to reiserfs.

(BTW perhaps, eventually, /proc/<pid>/maskfs is a better place - and the 
mask checking moves to vfs - all of a sudden it's not reiser specific - 
although maskfs is reiserfs code)

>>If you are limited to the semantic layer, then there's 
>>no stat node with which to play tricks. 
>>
>>I wonder if it would be feasible if masks only specified 
>>exclusions? If, for instance, the mask wanted to exclude /foo/*, 
>>then the directory foo would exist (in the mask semantic tree). 
>>To exclude /etc/passwd, passwd would exist in the directory /etc. 
>>Since you're already going to need to preempt dcache searches 
>>(aren't you?)
>>
>>Sigh, yes, or we need to use dcache for the mask.
>>    
>>
>>you can insert a search of the mask tree. If the 
>>search fails, then it is not excluded and the request falls through 
>>to normal VFS handling. In the /etc/passwd case above, it would find 
>>/etc/passwd and so the file is excluded. Processing would stop there, 
>>returning some error. How does this sound? 
>>
>>I don't quite understand this paragraph above.
>>    
>>
>Probably because I'm not on the same page as you and George.
>Imagine a filesystem with two trees: one, the real
>root filesystem and two, the anti-root tree (exclusions). This
>fs would be the root fs for the process. Let's say fooprocess has 
>the following exclusions:
>
>	/etc/passwd
>	/etc/shadow
>	/var
>
>Above, when I said "insert a search of the mask tree" what I meant was
>"first search the exception [semantic] tree (anti-tree) associated with 
>this process. If you find the object there, then report it as NOT FOUND.
>Otherwise, proceed with a normal fs tree search (fall-through).
>

Here's how I see parallel traversal and using masklets could work 
(purely semantic)
I don't know if this is feasible as I don't know if you could intertwine 
the fs/maskfs traversals.

The mask just contains: /etc/config.file

1. open (/etc/passwd)
search the maskfs for the first traversal point / : default - fall 
through to fs
search the fs for / - normal behaviour
search the maskfs for the traversal point etc/ : default - fall through 
to fs
search the fs for etc/ - normal behaviour
search the maskfs for the object passwd : not there -> file not found

2. open(/etc/config.file)
search the maskfs for the first traversal point / : default - fall 
through to fs
search the fs for / - normal behaviour
search the maskfs for the traversal point etc/ : default - fall through 
to fs
search the fs for etc/ - normal behaviour
search the maskfs for the object config.file : read only - fall through 
to fs _with masklet_
search the fs for object - apply masklet and return.

Note that in specifying /etc/config.file you infer a mask on / & /etc/
so maybe directorys mentioned in passing such as /etc/config.file imply
/ : x only
/etc : x only
/etc/config.file : masklet

of course this needs to be aligned with the comment at the start

This mask is interesting:
/etc : doesn't exist
/etc/config.file : r only

>>George:
>>To give a couple of examples:
>>    1) A given process (say a restricted shell) can not exec() an
>>        executable with the set-uid bit on.
>>         - directly
>>         - indirectly (e.g., via bash)
>>    2) Apache can only create/write files in /var/web/incoming.
>>         - files created or modified can not have any execute bit set 
>>and executing chmod is excluded.
>>
>>Hans:
>>this protection happens while traversing the mask or at the fall through 
>>point.
>>
Don't you always fall through - but sometimes you 'hit' a masklet and 
sometimes you 'miss'

>>  Hmmm, we need to accumulate a set of permissions that apply to 
>>something that are specific to how we got there.
>>
In fs traversal the permision at a point in traversal (ie a directory on 
the way) doesn't affect the permission of the object when the fs has 
been traversed except insofar as it may not be reachable. So why do you 
need to do this?
(I agree you need to check each traversal point against the mask)

As I said above: This mask is interesting:
/etc : doesn't exist
/etc/config.file : r only

it will report file not found due to a traversal failure - isn't that 
what you'd want?

>>  That could be complex 
>>in the VFS details.  We can defer it to Phase II if necessary.  George, 
>>you should spend a day (not this week) figuring out how much work it 
>>would be to make that work.  It will be the details of it that will be 
>>dangerous....
>>    
>>
>
>I'll tackle scenario #2:
>* Executing chmod would be excluded because it would not be visible in the mask.
>* "files created or modified can not have any execute bit set" 
>  Implicit in this statement is that, in addition to filtering object 
>  visibility, masks will preempt/proscribe certain fs operations -- in this 
>  case, the setting of certain attributes (i.e. exec bit). If this is correct
>  then what can masks allow/prohibit WRT operations/attributes performed
>  on objects. This is what I was trying to clarify with my earlier question.
>
>  
>
If you have a maskfs then if you traverse it for a filename and get a 
hit then the results of the hit are the masklet to be applied.

If you get a miss then implicit exclude states:
* doesn't exist (shortcut the call - file not found)

If it hits, what types are there in a masklet?
I think:
* doesn't exist (file not found)
* file attribute mask (eg: prevent any writing)
* acl 'mask' (an obvious extension of attr but no longer simple 'AND' logic)
* syscall mask (prevent hardlink and maybe chmod - although see below)
* 'umask' (chmod) mask (prevent setting suid or execute bit - but may 
allows setting +w and setgid on directories - may extend to acls too)

David

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 12342 bytes --]



David Greaves wrote:

> Hi
>
> I've been following and have an interest - I hope my comments and 
> observations are valuable.
>
> First, allow me to suggest some more terminology - like George, I 
> always like to see this done early
> Masklet : set of modifications to a filename's access authorisations
> Mask: collection of Masklets (possibly only 1)
>
> Most of the time one will use 'mask'; eg one can now traverse a mask 
> (cf an image overlay) however one can use masklet to refer to a 
> specific instance (a complex mask pixel)
> I've used this terminology below and I think it's OK.
>
> David Dabbs wrote:
>
>> Fall-Through Point
>> The point during some file operation at which it is determined that 
>> the file is not filtered by the mask. The request [for operation X on 
>> the file]
>> is passed on to the VFS/underlying filesystem. 
>
> This doesn't sound right.
> (Basically I suspect there has been confusion over 'visibilty' and 
> file attribute masking)
>
> When did masks specify visibility of files? According to Hans :


This is clearcase functionality so everyone assumed it from the original
posting http://www.namesys.com/blackbox_security.html

>
>> Hmm.  Yes, views should allow masking permissions.
>
>
>
> mind you, he then said:
>
>> We need to be able to support specifying a mask that allows any file 
>> within a given directory to be visible.  That is, we need to support 
>> dirname/* but we don't yet need to support dirname/foo.* 
>
>
>
> I think (see last paragraphs of this email) that we have a collection 
> of masklet types.
>
>>
>>
>> Features & Constraints
>> ----------------------------------------------------------------------
>> Masks - must support dirname/* - do not [yet] need to support 
>> dirname/foo.*
>> - should not allow symbolic link traversal unless the file pointed to 
>>  is within the mask.
>>  
>>
> simple question here:
> does dirname/* go deep into the directory tree??
>
> It doesn't in shell syntax
>
> Maybe dirname/**
> (which means the complete tree below dirname)
>
> Important I think.
> Also introduces the question of 'rule' interaction
>
> dirname/bar/foo : maska
> dirname/bar/*     : maskb
> dirname**           : mask c
>
> which mask?
> options:
> AND?
> most specific? (definition)
> first to match?


Probably first to match, just thinking in terms of lex.
Using every mask that applies is also potentially useful but raises more
performance concerns.

>
>
>> Masked Processes
>> - May not create hard links.
>> - Child processes [of a masked process] must inherit the parent's 
>>  "mask bit" and mask definition.
>>  
>>
> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
> filesystem?
> Hans actually says it's derived from the executable.
> What if it changes between two processes starting?
> Does the running processes mask change? (cf chmod a file - seems 
> reasonable but...)
> I'd think it needs to be pretty atomic...
> In fact, maybe changing masks on a running (mounted?) system is a 
> potential security hole and forbidden?
> I think I could think of race examples.


I am disinclined to tackle changing masks on the fly until I have a 
compelling story
to justify the work.

> aside: talking about reuse, maybe the recent lkml JOB patch is useful:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109278360210574&w=2
>
> +       A job is a group of related processes all descended from a
> +       point of entry process and  identified  by  a  unique  job
> +       identifier  (jid).   A  job  can     contain multiple process
> +       groups or sessions, and all processes in one of these sub-
> +       groups can only be contained within a single job.
> +
> +       The  primary  purpose  for  having  jobs is to provide job
> +       based resource limits.
>
> Maybe exe's can have something _like_ setuid? setmid()?
> mid being based on jid?


Thanks for the pointer.  I will take a look at this.

>
>> Questions
>> ----------------------------------------------------------------------
>>  
>>
>>> All file types and access methods will be supported, yes? (mmap, 
>>> AIO, DIRECT, pipes, hard/sym links, etc.)
>>>
>>> Hans: Yes.
>>> ...except that they cannot create hard links (above)
>>>   
>>
>>
>>
>> Is this restriction unequivocal (yes)? Any other forbidden Unix fs 
>> objects or fs operations?
>>  
>>
> Obviously creating a hardlink _can_ circumvent semantically specified 
> security.
> But shouldn't that just be a masklet attribute? see below (end)


Do you have an example in mind?
I share your belief but in a few minutes of thinking about it didn't
come up with a plausible example.

>>> Early on in the conversation, there was discussion about 
>>> "permissible functionality." At a minimum, a mask, true to its name, 
>>> will effect filesystem object _visibility_. It was not completely 
>>> clear whether the mask will be proscriptive viz operations. IOW, 
>>> will the mask say that fooprocess "is not permitted to [attempt to] 
>>> RWX object bar?" I believe this is not something masks will do, but 
>>> I wanted clarification.
>>>
>>>
>>> I don't know why I don't understand your question, but I don't.....;-)
>>>   
>>
>>
>>
>>
>> Let me try again. At a mininmum, a mask specifies what objects are
>> visible to a process, correct? If objext X is included in or not 
>> explicitly excluded from the mask, then fooprocess is allowed to 
>> _attempt_to_ operate on object X. I say "attempt to" because, at that 
>> point (fall-through), the mask is finished wrt the operation, yes? 
>> Permission to actually carry out an operation on object X is 
>> determined by the user/object/permission mapping in the underlying
>> filesystem.
>>
>> What was not clear to me was whether masks specified, proscribed, or
>> in any way controlled filesystem operations (permissions) for objects
>> that are visible when running under the mask. If so, what can be 
>> specified and is it an "allow" a "deny" or either?
>>  
>>
> So, you're saying that a mask can deny authorisation but not grant it.
> (In which case 'mask' is a good word and the concept of AND goes into 
> the foundations)


YES.

>
> A process can read/write/execute according to FS permissions.
> If the files 'acl/attr' doesn't allow writing then the mask _cannot_ 
> override this and allow a masked process to write to the file.
>
> This sounds sensible.


Glad everyone is on the same page with this

>
>>> Hans, in your preferred approach you referred to "a format that is 
>>> as if it is a subdirectory of the masked executable." Did you have
>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>> when exec() loads the exe,
>>>
>>> yes
>>>
>>> and if this exists then the files rooted in this directory would be 
>>> set as the process's root filesystem?
>>>
>>> Your statement is imprecise. The mask will be checked first, and 
>>> then iff it falls through we do a normal filesystem traversal.
>>>   
>>
>>
>>
>> It was imprecise because perhaps I had a different vprint concept and 
>> implementation in mind. Using the creation tool, JAdmin creates a 
>> mask for fooprocess. The mask would be a directory structure rooted 
>> at /bin/fooprocess/metas/mask. All files (not dirs) in this tree 
>> would be hard links to the "real" files specified in the mask. Only 
>> dirs & files included in the spec are visible. When an instance of 
>> fooprocess is started, /bin/fooprocess/metas/mask is automagically 
>> mounted as the process's root filesystem. The mask would be the 
>> filesystem. Other than the use of the metas reiserism (and mask 
>> maintenance wizardry)
>> this is not any different than chroot. Since the end result here is
>> to be no more secure than chroot, but very much easier to deploy and 
>> maintain, is there a reason why this cannot be the case?
>>  
>>
> I think the 'thing' at /usr/bin/fooprocess/metas/mask
> is a semantic expansion of the mask (ie it's like a directory tree but 
> it doesn't point to files, it just contains lots of masklets).
> It can be traversed in parallel to the real tree traversal and the 
> masklets it returns will modify the real results. It is purely 
> semantic. I've expanded this later.
>
> Call it a maskfs?
> The email subject becomes:
> Re: viewprinting: what format should maskfs use?
> The answer of course is something very similar to reiserfs.
>
> (BTW perhaps, eventually, /proc/<pid>/maskfs is a better place - and 
> the mask checking moves to vfs - all of a sudden it's not reiser 
> specific - although maskfs is reiserfs code)


Hans and I discussed this briefly.  For proof-of-concept work we agreed 
that having as much as possible
in the file system layer was the way to go.  If it proves to be viable 
then we can try to convince the rest
of the community.

>
>
>>> George:
>>> To give a couple of examples:
>>>    1) A given process (say a restricted shell) can not exec() an
>>>        executable with the set-uid bit on.
>>>         - directly
>>>         - indirectly (e.g., via bash)
>>>    2) Apache can only create/write files in /var/web/incoming.
>>>         - files created or modified can not have any execute bit set 
>>> and executing chmod is excluded.
>>>
>>> Hans:
>>> this protection happens while traversing the mask or at the fall 
>>> through point.
>>>
> Don't you always fall through - but sometimes you 'hit' a masklet and 
> sometimes you 'miss'


"Fall through" is to the original filesystem below the mask.  You don't 
fall through if the mask
rejects the operation.

>
>>>  Hmmm, we need to accumulate a set of permissions that apply to 
>>> something that are specific to how we got there.
>>>
> In fs traversal the permision at a point in traversal (ie a directory 
> on the way) doesn't affect the permission of the object when the fs 
> has been traversed except insofar as it may not be reachable. So why 
> do you need to do this?
> (I agree you need to check each traversal point against the mask)
>
> As I said above: This mask is interesting:
> /etc : doesn't exist
> /etc/config.file : r only
>
> it will report file not found due to a traversal failure - isn't that 
> what you'd want?


I suppose technically it is an optimization: but it makes sense that for 
some process
nothing in /etc is writable or nothing in /home/confidential is 
available at all.

I tend to think that in your example /etc/config.file is a useless 
masklet, but perhaps
if you change the order then the only file you see in /etc is config.file.

At the moment I need time to think about the mask interpreter layer and put
some "stakes in the ground" about what is actually practical to implement.

>
>>>  That could be complex in the VFS details.  We can defer it to Phase 
>>> II if necessary.  George, you should spend a day (not this week) 
>>> figuring out how much work it would be to make that work.  It will 
>>> be the details of it that will be dangerous....
>>>   
>>
>>
>>
>> I'll tackle scenario #2:
>> * Executing chmod would be excluded because it would not be visible 
>> in the mask.
>> * "files created or modified can not have any execute bit set" 
>>  Implicit in this statement is that, in addition to filtering object 
>>  visibility, masks will preempt/proscribe certain fs operations -- in 
>> this  case, the setting of certain attributes (i.e. exec bit). If 
>> this is correct
>>  then what can masks allow/prohibit WRT operations/attributes performed
>>  on objects. This is what I was trying to clarify with my earlier 
>> question.
>>
>>  
>>
> If you have a maskfs then if you traverse it for a filename and get a 
> hit then the results of the hit are the masklet to be applied.
>
> If you get a miss then implicit exclude states:
> * doesn't exist (shortcut the call - file not found)
>
> If it hits, what types are there in a masklet?
> I think:
> * doesn't exist (file not found)
> * file attribute mask (eg: prevent any writing)
> * acl 'mask' (an obvious extension of attr but no longer simple 'AND' 
> logic)
> * syscall mask (prevent hardlink and maybe chmod - although see below)
> * 'umask' (chmod) mask (prevent setting suid or execute bit - but may 
> allows setting +w and setgid on directories - may extend to acls too)


For proof of concept the first 2 suffice.
After that we are likely to be driven by practical considerations (e.g., 
what gets funded )



[-- Attachment #2.1: Type: text/html, Size: 16723 bytes --]

[-- Attachment #2.2: smile_n.gif --]
[-- Type: image/gif, Size: 144 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
>
>>
>>
>>> Masked Processes
>>> - May not create hard links.
>>> - Child processes [of a masked process] must inherit the parent's 
>>>  "mask bit" and mask definition.
>>>  
>>>
>> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
>> filesystem?
>> Hans actually says it's derived from the executable.
>> What if it changes between two processes starting?
>> Does the running processes mask change? (cf chmod a file - seems 
>> reasonable but...)
>> I'd think it needs to be pretty atomic...
>> In fact, maybe changing masks on a running (mounted?) system is a 
>> potential security hole and forbidden?
>> I think I could think of race examples.
>
>
> I am disinclined to tackle changing masks on the fly until I have a 
> compelling story
> to justify the work.

It is less work to allow changing them on the fly than to not do so, 
since they are stored in the fs, not something loaded into the process 
state.

Hans

Re: viewprinting: what format should views be stored in?

[Lamont R. Peterson]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Fri, 2004-08-20 at 00:19, Hans Reiser wrote:
> George Beshers wrote:
> >>> Masked Processes
> >>> - May not create hard links.
> >>> - Child processes [of a masked process] must inherit the parent's 
> >>>  "mask bit" and mask definition.
> >>>  
> >> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
> >> filesystem?
> >> Hans actually says it's derived from the executable.
> >> What if it changes between two processes starting?
> >> Does the running processes mask change? (cf chmod a file - seems 
> >> reasonable but...)
> >> I'd think it needs to be pretty atomic...
> >> In fact, maybe changing masks on a running (mounted?) system is a 
> >> potential security hole and forbidden?
> >> I think I could think of race examples.
> >
> > I am disinclined to tackle changing masks on the fly until I have a 
> > compelling story
> > to justify the work.
> 
> It is less work to allow changing them on the fly than to not do so, 
> since they are stored in the fs, not something loaded into the process 
> state.

Yes.

Additionally, if they could not be changed "on-the-fly", then in
practical terms this would force an admin to restart a daemon when a
change is made.  That would not be very friendly.
-- 
Lamont R. Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

Lamont R. Peterson wrote:

>On Fri, 2004-08-20 at 00:19, Hans Reiser wrote:
>  
>
>>George Beshers wrote:
>>    
>>
>>>>>Masked Processes
>>>>>- May not create hard links.
>>>>>- Child processes [of a masked process] must inherit the parent's 
>>>>> "mask bit" and mask definition.
>>>>> 
>>>>>          
>>>>>
>>>>remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
>>>>filesystem?
>>>>Hans actually says it's derived from the executable.
>>>>What if it changes between two processes starting?
>>>>Does the running processes mask change? (cf chmod a file - seems 
>>>>reasonable but...)
>>>>I'd think it needs to be pretty atomic...
>>>>In fact, maybe changing masks on a running (mounted?) system is a 
>>>>potential security hole and forbidden?
>>>>I think I could think of race examples.
>>>>        
>>>>
>>>I am disinclined to tackle changing masks on the fly until I have a 
>>>compelling story
>>>to justify the work.
>>>      
>>>
>>It is less work to allow changing them on the fly than to not do so, 
>>since they are stored in the fs, not something loaded into the process 
>>state.
>>    
>>
>
>Yes.
>
>Additionally, if they could not be changed "on-the-fly", then in
>practical terms this would force an admin to restart a daemon when a
>change is made.  That would not be very friendly.
>  
>
Yes, and actually, part of our objective is to allow for incremental 
improvements/refinements to the masks as we discover more files that the 
blackbox binary needs.

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> Lamont R. Peterson wrote:
>
>> On Fri, 2004-08-20 at 00:19, Hans Reiser wrote:
>>
>>
>>> George Beshers wrote:
>>>
>>>>>> Masked Processes
>>>>>> - May not create hard links.
>>>>>> - Child processes [of a masked process] must inherit the parent's 
>>>>>> "mask bit" and mask definition.
>>>>>>
>>>>>>
>>>>> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
>>>>> filesystem?
>>>>> Hans actually says it's derived from the executable.
>>>>> What if it changes between two processes starting?
>>>>> Does the running processes mask change? (cf chmod a file - seems 
>>>>> reasonable but...)
>>>>> I'd think it needs to be pretty atomic...
>>>>> In fact, maybe changing masks on a running (mounted?) system is a 
>>>>> potential security hole and forbidden?
>>>>> I think I could think of race examples.
>>>>>
>>>> I am disinclined to tackle changing masks on the fly until I have a 
>>>> compelling story
>>>> to justify the work.
>>>>
>>> It is less work to allow changing them on the fly than to not do so, 
>>> since they are stored in the fs, not something loaded into the 
>>> process state.
>>>
>>
>> Yes.
>>
>> Additionally, if they could not be changed "on-the-fly", then in
>> practical terms this would force an admin to restart a daemon when a
>> change is made. That would not be very friendly.
>>
>>
> Yes, and actually, part of our objective is to allow for incremental 
> improvements/refinements to the masks as we discover more files that 
> the blackbox binary needs.
>
All points above are sound---dynamic changes to masks will be supported
in the first implementation according to current thinking.

Still, a "batch mode" for production servers is a concept that should not be
discarded too quickly as static masks would certainly support a more
efficient implementation --- that the savings would be significant is still
very much an open question.

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>> Lamont R. Peterson wrote:
>>
>>> On Fri, 2004-08-20 at 00:19, Hans Reiser wrote:
>>>
>>>
>>>> George Beshers wrote:
>>>>
>>>>>>> Masked Processes
>>>>>>> - May not create hard links.
>>>>>>> - Child processes [of a masked process] must inherit the 
>>>>>>> parent's "mask bit" and mask definition.
>>>>>>>
>>>>>>>
>>>>>> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
>>>>>> filesystem?
>>>>>> Hans actually says it's derived from the executable.
>>>>>> What if it changes between two processes starting?
>>>>>> Does the running processes mask change? (cf chmod a file - seems 
>>>>>> reasonable but...)
>>>>>> I'd think it needs to be pretty atomic...
>>>>>> In fact, maybe changing masks on a running (mounted?) system is a 
>>>>>> potential security hole and forbidden?
>>>>>> I think I could think of race examples.
>>>>>>
>>>>> I am disinclined to tackle changing masks on the fly until I have 
>>>>> a compelling story
>>>>> to justify the work.
>>>>>
>>>> It is less work to allow changing them on the fly than to not do 
>>>> so, since they are stored in the fs, not something loaded into the 
>>>> process state.
>>>>
>>>
>>> Yes.
>>>
>>> Additionally, if they could not be changed "on-the-fly", then in
>>> practical terms this would force an admin to restart a daemon when a
>>> change is made. That would not be very friendly.
>>>
>>>
>> Yes, and actually, part of our objective is to allow for incremental 
>> improvements/refinements to the masks as we discover more files that 
>> the blackbox binary needs.
>>
> All points above are sound---dynamic changes to masks will be supported
> in the first implementation according to current thinking.
>
> Still, a "batch mode" for production servers is a concept that should 
> not be
> discarded too quickly as static masks would certainly support a more
> efficient implementation

I dispute this point. What do you think would be more efficient than 
reiser4 directories? Or are you referring to compiled regular expressions?

> --- that the savings would be significant is still
> very much an open question.
>
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

Hans Reiser wrote:

> George Beshers wrote:
>
>>
>>
>>
>>
>> Still, a "batch mode" for production servers is a concept that should 
>> not be
>> discarded too quickly as static masks would certainly support a more
>> efficient implementation
>
>
> I dispute this point. What do you think would be more efficient than 
> reiser4 directories? Or are you referring to compiled regular 
> expressions?
>
Only as a secondary issue. I was thinking about the possibility of a 
linked-list of static masks.
In that case it would make sense to form a single "composed" mask which 
allows access to
just the objects that all the masks allow---basically a set intersection.

Further, an interesting algorithm would be to do the intersection 
lazily, i.e., so that the composed
mask actually is created only for those objects (or perhaps just 
directories) actually in a path.
Obviously the case where this wins is when there are a lot of open calls 
to some directory.

BTW: we might call a view (as in the database sense) the "mask + name 
mangling + ..." as Lamont's
comment rings true.

Also, I downloaded a paper on evaluating RE which I can send along if 
you and Nate are interested.


>> --- that the savings would be significant is still
>> very much an open question.
>>
>>
>>
>
>
>

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>> George Beshers wrote:
>>
>>>
>>>
>>>
>>>
>>> Still, a "batch mode" for production servers is a concept that 
>>> should not be
>>> discarded too quickly as static masks would certainly support a more
>>> efficient implementation
>>
>>
>>
>> I dispute this point. What do you think would be more efficient than 
>> reiser4 directories? Or are you referring to compiled regular 
>> expressions?
>>
> Only as a secondary issue. I was thinking about the possibility of a 
> linked-list of static masks.
> In that case it would make sense to form a single "composed" mask 
> which allows access to
> just the objects that all the masks allow---basically a set intersection.
>
> Further, an interesting algorithm would be to do the intersection 
> lazily, i.e., so that the composed
> mask actually is created only for those objects (or perhaps just 
> directories) actually in a path.
> Obviously the case where this wins is when there are a lot of open 
> calls to some directory.
>
> BTW: we might call a view (as in the database sense) the "mask + name 
> mangling + ..." as Lamont's
> comment rings true.

Let's get the 80% done, and leave the 20% refinements which are as much 
code as the 80% for later.;-)

>
> Also, I downloaded a paper on evaluating RE which I can send along if 
> you and Nate are interested.

Send it when we get to evaluating REs, and I will be interested then.

>
>
>>> --- that the savings would be significant is still
>>> very much an open question.
>>>
>>>
>>>
>>
>>
>>
>
>
>

Re: viewprinting: what format should views be stored in?

[David Greaves]

George Beshers wrote:

>> This doesn't sound right.
>> (Basically I suspect there has been confusion over 'visibilty' and 
>> file attribute masking)
>>
>> When did masks specify visibility of files? According to Hans :
>
>
> This is clearcase functionality so everyone assumed it from the original
> posting http://www.namesys.com/blackbox_security.html

yes.

It was Hans' subsequent: "Hmm.  Yes, views should allow masking 
permissions. "
which implies that requirements are that the mask doesn't just have a 
binary value:
not there / see filesystem
but actually each masklet contains a bitmask (or similar) to be ANDed 
with the attr from the fs *and* a there/not-there bit.

Trying for clarity in the role of the mask interpreter layer.
Does the mask act as a gatekeeper - passing things through to the fs 
(possibly simpler to implement but _far_ less functional)
Or (more likely) does the mask layer take over the role of authoriser(?) 
in which case it delegates to the fs for the fs authorisation (attr) and 
then bitwise ANDs that with it's own masklet (maybe shortcutting if the 
mask determines the file is invisible)

I think we all agree on the latter but I thought it best to be clear.

>> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
>> filesystem?
>> Hans actually says it's derived from the executable.
>> What if it changes between two processes starting?
>> Does the running processes mask change? (cf chmod a file - seems 
>> reasonable but...)
>> I'd think it needs to be pretty atomic...
>> In fact, maybe changing masks on a running (mounted?) system is a 
>> potential security hole and forbidden?
>> I think I could think of race examples.
>
>
> I am disinclined to tackle changing masks on the fly until I have a 
> compelling story
> to justify the work.

ok - agreed.
Also here's a possible issue:
masklet is dirname/*
open dirname for reading
replace masklet with multiple masklets dirname/a;dirname/b;dirname/c;
someone creates file dirname/d
Can I see it from a read of still open dirname/ ?
I shouldn't be able to.

This is security stuff so I'd say that masks are set at mount-time and 
imutable thereafter?

(errm, sorry, I read your email and wrote this and then noticed it was 
the *next*section you asked for an example - anyway I'll leave this one in)


>> Obviously creating a hardlink _can_ circumvent semantically specified 
>> security.
>> But shouldn't that just be a masklet attribute? see below (end)
>
>
> Do you have an example in mind?
> I share your belief but in a few minutes of thinking about it didn't
> come up with a plausible example.

links are based on the filename
changing the filename changes the masklet applied.
maskspec:
/var/logs/* : readonly
/var/tmp/scratch/ : full access

a file in /var/log has 666 (by mistake)
ln it to /var/tmp/scratch and you can now edit it - breaking the mask.
(so, to be clear, I think they should  be allowed but only when the 
maskspec/interpreter allows them to be filtered - ie phase 1 disallows 
hardlinks, a future phase could handle them properly)

>>>> Hans, in your preferred approach you referred to "a format that is 
>>>> as if it is a subdirectory of the masked executable." Did you have
>>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>>> when exec() loads the exe,
>>>>
>>>> yes
>>>>
>>>> and if this exists then the files rooted in this directory would be 
>>>> set as the process's root filesystem?
>>>>
>>>> Your statement is imprecise. The mask will be checked first, and 
>>>> then iff it falls through we do a normal filesystem traversal.
>>>>   
>>>
>>>
>>>
>>> It was imprecise because perhaps I had a different vprint concept 
>>> and implementation in mind. Using the creation tool, JAdmin creates 
>>> a mask for fooprocess. The mask would be a directory structure 
>>> rooted at /bin/fooprocess/metas/mask. All files (not dirs) in this 
>>> tree would be hard links to the "real" files specified in the mask. 
>>> Only dirs & files included in the spec are visible. When an instance 
>>> of fooprocess is started, /bin/fooprocess/metas/mask is 
>>> automagically mounted as the process's root filesystem. The mask 
>>> would be the filesystem. Other than the use of the metas reiserism 
>>> (and mask maintenance wizardry)
>>> this is not any different than chroot. Since the end result here is
>>> to be no more secure than chroot, but very much easier to deploy and 
>>> maintain, is there a reason why this cannot be the case?
>>>  
>>>
>> I think the 'thing' at /usr/bin/fooprocess/metas/mask
>> is a semantic expansion of the mask (ie it's like a directory tree 
>> but it doesn't point to files, it just contains lots of masklets).
>> It can be traversed in parallel to the real tree traversal and the 
>> masklets it returns will modify the real results. It is purely 
>> semantic. I've expanded this later.
>>
>> Call it a maskfs?
>> The email subject becomes:
>> Re: viewprinting: what format should maskfs use?
>> The answer of course is something very similar to reiserfs.
>>
>> (BTW perhaps, eventually, /proc/<pid>/maskfs is a better place - and 
>> the mask checking moves to vfs - all of a sudden it's not reiser 
>> specific - although maskfs is reiserfs code)
>
>
> Hans and I discussed this briefly.  For proof-of-concept work we 
> agreed that having as much as possible
> in the file system layer was the way to go.  If it proves to be viable 
> then we can try to convince the rest
> of the community.

Sorry, the /proc bit was very much an aside.

What I was really interested in was the parallel/concurrent traversing 
of the fs tree and the maskfs idea.
ie check / in mask then fs, check dir1 in mask then fs, check dir2 in 
mask then fs, finally check filename in mask then fs (rinse and repeat 
for symlinks)
This would increase the directory traversal time but it would be a 
constant factor.

I was also interested in what would essentially be a read only reiser 
filesystem with only directories.
One issue is having directory entries that match dirname/**
I wondered about storing the masks in the directories in the 
inode/acl/attr space.
The issue is then mkfs'ing a maskfs from a set of masklets (rules?, 
presentation mask?)

>> Don't you always fall through - but sometimes you 'hit' a masklet and 
>> sometimes you 'miss'
>
>
> "Fall through" is to the original filesystem below the mask.  You 
> don't fall through if the mask
> rejects the operation.

Hmm I think this is a speech vs email kind of misunderstanding. I think 
we agree.
I'd argue that you always need the mask and the fs to perform an AND.
in the case where the mask says 'invisible' (by specification or 
implicitly) then there is an optimisation where you don't need to check 
the fs - but this isn't very interesting :)
Most of the time I'd expect to be doing attr ANDs
(unless the app was actually probing about the fs where it has no right to!)
In fact an implicit fallthrough is worthy of reporting.

At one point I assumed there is no difference between file-not-found and 
invisible.
There isn't to the app. But you musn't forget monitoring. If an attempt 
is made to access an invisible file (whether or not it exists), this 
should go to a security log.

Also someone asked if you could tell you were being masked. The answer 
may be yes if you look at indirects such as time taken to return a 
file-not-found or could see a log.

>
>>
>>>>  Hmmm, we need to accumulate a set of permissions that apply to 
>>>> something that are specific to how we got there.
>>>>
>> In fs traversal the permision at a point in traversal (ie a directory 
>> on the way) doesn't affect the permission of the object when the fs 
>> has been traversed except insofar as it may not be reachable. So why 
>> do you need to do this?
>> (I agree you need to check each traversal point against the mask)
>>
>> As I said above: This mask is interesting:
>> /etc : doesn't exist
>> /etc/config.file : r only
>>
>> it will report file not found due to a traversal failure - isn't that 
>> what you'd want?
>
>
> I suppose technically it is an optimization: but it makes sense that 
> for some process
> nothing in /etc is writable or nothing in /home/confidential is 
> available at all.
>
> I tend to think that in your example /etc/config.file is a useless 
> masklet, but perhaps
> if you change the order then the only file you see in /etc is 
> config.file.

yes indeed. It was supposed to be 'useless'
It was about showing the 'accumulation of permissions specific to how we 
got there'

>
> At the moment I need time to think about the mask interpreter layer 
> and put
> some "stakes in the ground" about what is actually practical to 
> implement.

see above about maskfs :)
How about mounting maskfs's?
mkfs -tmaskfs -ospec=/etc/presentation_mask.spec /etc/maskfs_file
loopback mount the /etc/maskfs_file to the appropriate location
Hijack the reiserfs(?) access/traversal functions (can you - I dunno!) 
check for jid and if it exists then use it to determine where to look 
for the maskfs /. Then use the parallel traversal technique to retrieve 
a masklet and overlay it on the attr.


>> If you have a maskfs then if you traverse it for a filename and get a 
>> hit then the results of the hit are the masklet to be applied.
>>
>> If you get a miss then implicit exclude states:
>> * doesn't exist (shortcut the call - file not found)
>>
>> If it hits, what types are there in a masklet?
>> I think:
>> * doesn't exist (file not found)
>> * file attribute mask (eg: prevent any writing)
>> * acl 'mask' (an obvious extension of attr but no longer simple 'AND' 
>> logic)
>> * syscall mask (prevent hardlink and maybe chmod - although see below)
>> * 'umask' (chmod) mask (prevent setting suid or execute bit - but may 
>> allows setting +w and setgid on directories - may extend to acls too)
>
>
>
> For proof of concept the first 2 suffice.

That's why they were the first two :) I prioritised them at first but 
then thought I'd leave that 'til someone at the code said what was easy.

> After that we are likely to be driven by practical considerations 
> (e.g., what gets funded :-) )

yep - but I thought it worth identifying these for design purposes - and 
to maybe show how to tackle the other issues (acl, chmod, hardlinks, 
suid, umask etc)

Still worth prodding to see where the right place for such a thing is - 
it may be vfs - and designing in such a way as to make migration to 
there work in the future.

David
PS can I offer 'mask specification' (shortened to maskspec above) 
instead of 'presentation mask' for the glossary.

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

David Greaves wrote:

>
> David
> PS can I offer 'mask specification' (shortened to maskspec above) 
> instead of 'presentation mask' for the glossary.
>
>
Glossary? of?

Instead of mask specification, just say mask.

I think I like mask more than view....

Hans

Re: viewprinting: what format should views be stored in?

[George Beshers]

I used "presentation mask" for "source mask", i.e., something that was
portable and nominally human readable. I am anticipating a compilation
process to achieve performance.

Let us go with mask for now: source and compiled modifiers when
clarity is needed.

Hans Reiser wrote:

> David Greaves wrote:
>
>>
>> David
>> PS can I offer 'mask specification' (shortened to maskspec above) 
>> instead of 'presentation mask' for the glossary.
>>
>>
> Glossary? of?
>
> Instead of mask specification, just say mask.
>
> I think I like mask more than view....
>
> Hans
>

Re: viewprinting: what format should views be stored in?

[David Greaves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:

| David Greaves wrote:
|
|>
|> David
|> PS can I offer 'mask specification' (shortened to maskspec above)
|> instead of 'presentation mask' for the glossary.
|>
|>
| Glossary? of?

terms.
There have been occasional mails that try and clarify what we're
talking about.
I think they're helpful.

|
| Instead of mask specification, just say mask.

One way:
I write a mask each line of which is a mask and then the mask compiler
turns it into a mask that the mask interpreter uses to mask the
permissions?
Q: What's the role of the mask?

Another way:
I write a mask specification each line of which is a masklet and then
the mask compiler turns it  into a maskfs that the mask interpreter
uses to modify the permissions?
Q: What's the role of the mask specification?

Confusion is bad.

Nb in conversation then of course we say 'first, write a mask' - lets
just agree the terminology for clarifying the followon questions.

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBJgWl8LvjTle4P1gRAr6jAJ9/0QgHDHWn54yRUMhdqpXp2xL19ACfTvey
NRGxwKOw87X0IQs5uLiVqrY=
=izE8
-----END PGP SIGNATURE-----

Re: viewprinting: what format should views be stored in?

[Lamont R. Peterson]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Fri, 2004-08-20 at 00:52, Hans Reiser wrote:
> David Greaves wrote:
> 
> >
> > David
> > PS can I offer 'mask specification' (shortened to maskspec above) 
> > instead of 'presentation mask' for the glossary.
> >
> >
> Glossary? of?
> 
> Instead of mask specification, just say mask.
> 
> I think I like mask more than view....

I respectfully disagree.  I like view better than mask.  After all, the
term mask is used in lots of places already.  If you want to distinguish
viewprinting from those things, I think "view" is the way to go.

Also, I think view is more accurately descriptive of what it is that you
are trying to accomplish here.  It is also a more accurate term for us
database people :-).
-- 
Lamont R. Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: viewprinting: what format should views be stored in?

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lamont R. Peterson wrote:
| On Fri, 2004-08-20 at 00:52, Hans Reiser wrote:
|
|>David Greaves wrote:
|>
|>
|>>David
|>>PS can I offer 'mask specification' (shortened to maskspec above)
|>>instead of 'presentation mask' for the glossary.
|>>
|>>
|>
|>Glossary? of?
|>
|>Instead of mask specification, just say mask.
|>
|>I think I like mask more than view....
|
|
| I respectfully disagree.  I like view better than mask.  After all, the
| term mask is used in lots of places already.  If you want to distinguish
| viewprinting from those things, I think "view" is the way to go.

Trust me to speak up on the least important issues...

What about mask/view, or maskview?  People can abbreviate how they like,
and it's actually not a bad metaphor -- think of the "view" you get
through a "mask", such as a Halloween mask.  The eye holes aren't
terribly big, so you see a much smaller part of the world.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQX70BXgHNmZLgCUhAQLOKg//bLDAoPOR3VrAhDsjMTvndgjmSa5GohAL
Y+Sb6BaLbKIpxVv8WsB9x8t7xsqRPRqWOi7NLsfkDPWV3TH0YXVKEsjR44d4SOBv
/MEU4BQwaiwSpJry/FpkfFn5mc8bkV4HubTV6s3sk6qLsWVb3WOIXiHD5n9ppTqu
6qfU4z8WpttIAg1u49CSfc10GdQ4TKwNp9vvPl32EIdo58hp9XrEfLfb9J9byTXg
R51cvZVNi3RJohjvvp/wqy7JxvRjUl9Cd6NliHvE/NCQrk0MhiSE7od+d5B17DCZ
TonxOhk9OCyW2/d4SLQHtKMoNFXzaGQKO6haIE2ZGWr2W5DAmdZM32C7rz07f5+V
CCu/TtLxfnsZ0JLWAUAf4m7e1Q/vx3YtOI/IEHFPMjThoPCiROoUIQwlvV44Y7+w
3YJfmwHfQ4I8g8PvdbR2CdXcYD4ot2XrcEhbQu0aqVUgUWoGGndIyN0AyHV91NFr
aRVb6JuE95HUNXy8njakEuFvs29UjG0mlpJSMw3KEFPtEeWMlCxsE2hWpgB1FJK1
P+r/WTBGCdj4NIldl3unPtcXuq/ndxwiiZvOJ1Av2B6M1dBHAlX3Zsqyln/4FJyu
JHlSQYaRB0d4RS6/hcKzuxYscgNF3Sf0rlyRgPl3DFMQkBweVDh4TLlfrIU/ERoW
A6D6idBjrog=
=s5yB
-----END PGP SIGNATURE-----

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

David Greaves wrote:

> Hi
>
> I've been following and have an interest - I hope my comments and 
> observations are valuable.
>
> First, allow me to suggest some more terminology - like George, I 
> always like to see this done early :)
> Masklet : set of modifications to a filename's access authorisations
> Mask: collection of Masklets (possibly only 1)
>
> Most of the time one will use 'mask'; eg one can now traverse a mask 
> (cf an image overlay) however one can use masklet to refer to a 
> specific instance (a complex mask pixel)
> I've used this terminology below and I think it's OK.
>
> David Dabbs wrote:
>
>> Fall-Through Point
>> The point during some file operation at which it is determined that 
>> the file is not filtered by the mask. The request [for operation X on 
>> the file]
>> is passed on to the VFS/underlying filesystem.  
>>
> This doesn't sound right.
> (Basically I suspect there has been confusion over 'visibilty' and 
> file attribute masking)
>
> When did masks specify visibility of files? According to Hans :
>
>> Hmm.  Yes, views should allow masking permissions.
>
>
> mind you, he then said:
>
>> We need to be able to support specifying a mask that allows any file 
>> within a given directory to be visible.  That is, we need to support 
>> dirname/* but we don't yet need to support dirname/foo.* 
>
>
> I think (see last paragraphs of this email) that we have a collection 
> of masklet types.
>
>>
>>
>> Features & Constraints
>> ----------------------------------------------------------------------
>> Masks - must support dirname/* - do not [yet] need to support 
>> dirname/foo.*
>> - should not allow symbolic link traversal unless the file pointed to 
>>  is within the mask.
>>  
>>
> simple question here:
> does dirname/* go deep into the directory tree??

Yes, it does.

>
> It doesn't in shell syntax
>
> Maybe dirname/**
> (which means the complete tree below dirname)
>
> Important I think.
> Also introduces the question of 'rule' interaction
>
> dirname/bar/foo : maska
> dirname/bar/*     : maskb
> dirname**           : mask c
>
> which mask?
> options:
> AND?
> most specific? (definition)
> first to match?

Not sure I understand the question, but I'll guess.  The answer is that 
masks are anded, and have an order.

>
>
>> Masked Processes
>> - May not create hard links.
>> - Child processes [of a masked process] must inherit the parent's 
>>  "mask bit" and mask definition.
>>  
>>
> remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? 
> filesystem?

process running.

> Hans actually says it's derived from the executable.
> What if it changes between two processes starting?

then it changes for both processes.

> Does the running processes mask change? (cf chmod a file - seems 
> reasonable but...)
> I'd think it needs to be pretty atomic...
> In fact, maybe changing masks on a running (mounted?) system is a 
> potential security hole and forbidden?
> I think I could think of race examples.
>
> aside: talking about reuse, maybe the recent lkml JOB patch is useful:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109278360210574&w=2
>
> +       A job is a group of related processes all descended from a
> +       point of entry process and  identified  by  a  unique  job
> +       identifier  (jid).   A  job  can     contain multiple process
> +       groups or sessions, and all processes in one of these sub-
> +       groups can only be contained within a single job.
> +
> +       The  primary  purpose  for  having  jobs is to provide job
> +       based resource limits.

Ok with me.  I leave it to George.

>
> Maybe exe's can have something _like_ setuid? setmid()?
> mid being based on jid?

?

>
>> Questions
>> ----------------------------------------------------------------------
>>  
>>
>>> All file types and access methods will be supported, yes? (mmap, 
>>> AIO, DIRECT, pipes, hard/sym links, etc.)
>>>
>>> Hans: Yes.
>>> ...except that they cannot create hard links (above)
>>>   
>>
>>
>> Is this restriction unequivocal (yes)? Any other forbidden Unix fs 
>> objects or fs operations?
>>  
>>
> Obviously creating a hardlink _can_ circumvent semantically specified 
> security.
> But shouldn't that just be a masklet attribute? see below (end)
>
>>> Early on in the conversation, there was discussion about 
>>> "permissible functionality." At a minimum, a mask, true to its name, 
>>> will effect filesystem object _visibility_. It was not completely 
>>> clear whether the mask will be proscriptive viz operations. IOW, 
>>> will the mask say that fooprocess "is not permitted to [attempt to] 
>>> RWX object bar?" I believe this is not something masks will do, but 
>>> I wanted clarification.
>>>
>>>
>>> I don't know why I don't understand your question, but I don't.....;-)
>>>   
>>
>>
>>
>> Let me try again. At a mininmum, a mask specifies what objects are
>> visible to a process, correct? If objext X is included in or not 
>> explicitly excluded from the mask, then fooprocess is allowed to 
>> _attempt_to_ operate on object X. I say "attempt to" because, at that 
>> point (fall-through), the mask is finished wrt the operation, yes? 
>> Permission to actually carry out an operation on object X is 
>> determined by the user/object/permission mapping in the underlying
>> filesystem.
>>
>> What was not clear to me was whether masks specified, proscribed, or
>> in any way controlled filesystem operations (permissions) for objects
>> that are visible when running under the mask. If so, what can be 
>> specified and is it an "allow" a "deny" or either?
>>  
>>
> So, you're saying that a mask can deny authorisation but not grant it.

Yes.

> (In which case 'mask' is a good word and the concept of AND goes into 
> the foundations)
>
> A process can read/write/execute according to FS permissions.
> If the files 'acl/attr' doesn't allow writing then the mask _cannot_ 
> override this and allow a masked process to write to the file.
>
> This sounds sensible.
>
>>> Hans, in your preferred approach you referred to "a format that is 
>>> as if it is a subdirectory of the masked executable." Did you have
>>> in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>> when exec() loads the exe,
>>>
>>> yes
>>>
>>> and if this exists then the files rooted in this directory would be 
>>> set as the process's root filesystem?
>>>
>>> Your statement is imprecise. The mask will be checked first, and 
>>> then iff it falls through we do a normal filesystem traversal.
>>>   
>>
>>
>> It was imprecise because perhaps I had a different vprint concept and 
>> implementation in mind. Using the creation tool, JAdmin creates a 
>> mask for fooprocess. The mask would be a directory structure rooted 
>> at /bin/fooprocess/metas/mask. All files (not dirs) in this tree 
>> would be hard links to the "real" files specified in the mask. 
>
No, I don't like this.

>> Only dirs & files included in the spec are visible. When an instance 
>> of fooprocess is started, /bin/fooprocess/metas/mask is automagically 
>> mounted as the process's root filesystem. The mask would be the 
>> filesystem. Other than the use of the metas reiserism (and mask 
>> maintenance wizardry)
>> this is not any different than chroot. Since the end result here is
>> to be no more secure than chroot, but very much easier to deploy and 
>> maintain, is there a reason why this cannot be the case?
>>  
>>
> I think the 'thing' at /usr/bin/fooprocess/metas/mask
> is a semantic expansion of the mask (ie it's like a directory tree but 
> it doesn't point to files, it just contains lots of masklets).
> It can be traversed in parallel to the real tree traversal and the 
> masklets it returns will modify the real results. It is purely 
> semantic. I've expanded this later.
>
> Call it a maskfs?
> The email subject becomes:
> Re: viewprinting: what format should maskfs use?
> The answer of course is something very similar to reiserfs.
>
> (BTW perhaps, eventually, /proc/<pid>/maskfs is a better place - and 
> the mask checking moves to vfs - all of a sudden it's not reiser 
> specific - although maskfs is reiserfs code)
>
>>> If you are limited to the semantic layer, then there's no stat node 
>>> with which to play tricks.
>>> I wonder if it would be feasible if masks only specified exclusions? 
>>> If, for instance, the mask wanted to exclude /foo/*, then the 
>>> directory foo would exist (in the mask semantic tree). To exclude 
>>> /etc/passwd, passwd would exist in the directory /etc. Since you're 
>>> already going to need to preempt dcache searches (aren't you?)
>>>
>>> Sigh, yes, or we need to use dcache for the mask.
>>>   
>>> you can insert a search of the mask tree. If the search fails, then 
>>> it is not excluded and the request falls through to normal VFS 
>>> handling. In the /etc/passwd case above, it would find /etc/passwd 
>>> and so the file is excluded. Processing would stop there, returning 
>>> some error. How does this sound?
>>> I don't quite understand this paragraph above.
>>>   
>>
>> Probably because I'm not on the same page as you and George.
>> Imagine a filesystem with two trees: one, the real
>> root filesystem and two, the anti-root tree (exclusions). This
>> fs would be the root fs for the process. Let's say fooprocess has the 
>> following exclusions:
>>
>>     /etc/passwd
>>     /etc/shadow
>>     /var
>>
>> Above, when I said "insert a search of the mask tree" what I meant was
>> "first search the exception [semantic] tree (anti-tree) associated 
>> with this process. If you find the object there, then report it as 
>> NOT FOUND.
>> Otherwise, proceed with a normal fs tree search (fall-through).
>
I suppose it could work.  Ok.  Phase II.  Should go into final report 
for Phase I.

>>
>
> Here's how I see parallel traversal and using masklets could work 
> (purely semantic)
> I don't know if this is feasible as I don't know if you could 
> intertwine the fs/maskfs traversals.
>
> The mask just contains: /etc/config.file
>
> 1. open (/etc/passwd)
> search the maskfs for the first traversal point / : default - fall 
> through to fs
> search the fs for / - normal behaviour
> search the maskfs for the traversal point etc/ : default - fall 
> through to fs
> search the fs for etc/ - normal behaviour
> search the maskfs for the object passwd : not there -> file not found

No, / is not a fall through point, only /etc/config.file is.  There is 
no need to see if the underlying fs allows something if the mask does 
not.  The mask is fully traversed, and only if we hit a fall through 
point do we go to the underlying fs, and if we go to the underlying fs, 
we only come up to the mask again for symlinks.

>
> 2. open(/etc/config.file)
> search the maskfs for the first traversal point / : default - fall 
> through to fs
> search the fs for / - normal behaviour
> search the maskfs for the traversal point etc/ : default - fall 
> through to fs
> search the fs for etc/ - normal behaviour
> search the maskfs for the object config.file : read only - fall 
> through to fs _with masklet_
> search the fs for object - apply masklet and return.
>
> Note that in specifying /etc/config.file you infer a mask on / & /etc/
> so maybe directorys mentioned in passing such as /etc/config.file imply
> / : x only
> /etc : x only
> /etc/config.file : masklet
>
> of course this needs to be aligned with the comment at the start
>
> This mask is interesting:
> /etc : doesn't exist
> /etc/config.file : r only
>
>>> George:
>>> To give a couple of examples:
>>>    1) A given process (say a restricted shell) can not exec() an
>>>        executable with the set-uid bit on.
>>>         - directly
>>>         - indirectly (e.g., via bash)
>>>    2) Apache can only create/write files in /var/web/incoming.
>>>         - files created or modified can not have any execute bit set 
>>> and executing chmod is excluded.
>>>
>>> Hans:
>>> this protection happens while traversing the mask or at the fall 
>>> through point.
>>>
> Don't you always fall through - but sometimes you 'hit' a masklet and 
> sometimes you 'miss'
>
>>>  Hmmm, we need to accumulate a set of permissions that apply to 
>>> something that are specific to how we got there.
>>>
> In fs traversal the permision at a point in traversal (ie a directory 
> on the way) doesn't affect the permission of the object when the fs 
> has been traversed except insofar as it may not be reachable. So why 
> do you need to do this?
> (I agree you need to check each traversal point against the mask)
>
> As I said above: This mask is interesting:
> /etc : doesn't exist
> /etc/config.file : r only
>
> it will report file not found due to a traversal failure - isn't that 
> what you'd want?
>
>>>  That could be complex in the VFS details.  We can defer it to Phase 
>>> II if necessary.  George, you should spend a day (not this week) 
>>> figuring out how much work it would be to make that work.  It will 
>>> be the details of it that will be dangerous....
>>>   
>>
>>
>> I'll tackle scenario #2:
>> * Executing chmod would be excluded because it would not be visible 
>> in the mask.
>> * "files created or modified can not have any execute bit set" 
>>  Implicit in this statement is that, in addition to filtering object 
>>  visibility, masks will preempt/proscribe certain fs operations -- in 
>> this  case, the setting of certain attributes (i.e. exec bit). If 
>> this is correct
>>  then what can masks allow/prohibit WRT operations/attributes performed
>>  on objects. This is what I was trying to clarify with my earlier 
>> question.
>>
>>  
>>
> If you have a maskfs then if you traverse it for a filename and get a 
> hit then the results of the hit are the masklet to be applied.
>
> If you get a miss then implicit exclude states:
> * doesn't exist (shortcut the call - file not found)
>
> If it hits, what types are there in a masklet?
> I think:
> * doesn't exist (file not found)
> * file attribute mask (eg: prevent any writing)
> * acl 'mask' (an obvious extension of attr but no longer simple 'AND' 
> logic)
> * syscall mask (prevent hardlink and maybe chmod - although see below)
> * 'umask' (chmod) mask (prevent setting suid or execute bit - but may 
> allows setting +w and setgid on directories - may extend to acls too)
>
> David
>
>

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 7584 bytes --]



David Dabbs wrote:

>
>
>Questions
>----------------------------------------------------------------------
>  
>
>>All file types and access methods will be supported, yes? 
>>(mmap, AIO, DIRECT, pipes, hard/sym links, etc.)
>>
>>Hans: Yes.
>>...except that they cannot create hard links (above)
>>    
>>
>
>Is this restriction unequivocal (yes)? 
>Any other forbidden Unix fs objects or fs operations?
>
>  
>
It needs further study which Hans and I have agreed to postpone
until after we have something working.

>  
>
>>Early on in the conversation, there was discussion about 
>>"permissible functionality." At a minimum, a mask, true to its name, 
>>will effect filesystem object _visibility_. It was not completely 
>>clear whether the mask will be proscriptive viz operations. IOW, will 
>>the mask say that fooprocess "is not permitted to [attempt to] RWX 
>>object bar?" I believe this is not something masks will do, but I 
>>wanted clarification.
>>
>>
>>I don't know why I don't understand your question, but I don't.....;-)
>>    
>>
>
>
>Let me try again. At a mininmum, a mask specifies what objects are
>visible to a process, correct? If objext X is included in or not 
>explicitly excluded from the mask, then fooprocess is allowed to 
>_attempt_to_ operate on object X. I say "attempt to" because, at 
>that point (fall-through), the mask is finished wrt the operation, 
>yes? Permission to actually carry out an operation on object X is 
>determined by the user/object/permission mapping in the underlying
>filesystem.
>
>What was not clear to me was whether masks specified, proscribed, or
>in any way controlled filesystem operations (permissions) for objects
>that are visible when running under the mask. If so, what can be 
>specified and is it an "allow" a "deny" or either?
>  
>
The answer is yes... but the extent of the control is an open question.

 - We have agreed not to mess with UIDs and GIDs or the associated
    set-uid and set-gid bits for the moment.
 - We have agreed that a mask which limits the operations on a visible
   file is appropriate, e.g., read-only should be supported.

Beyond that we will be driven largely by the perceived utility of the
functionality within the context of usual software engineering concerns.

>
>  
>
>>Hans, in your preferred approach you referred to "a format that 
>>is as if it is a subdirectory of the masked executable." Did you have
>>in mind checking for something like /usr/bin/fooprocess/metas/mask 
>>when exec() loads the exe,
>>
>>yes
>>
>>and if this exists then the files rooted in this directory 
>>would be set as the process's root filesystem?
>>
>>Your statement is imprecise. The mask will be checked first, and 
>>then iff it falls through we do a normal filesystem traversal.
>>    
>>
>
>It was imprecise because perhaps I had a different vprint concept 
>and implementation in mind. Using the creation tool, JAdmin creates 
>a mask for fooprocess. The mask would be a directory structure 
>rooted at /bin/fooprocess/metas/mask. All files (not dirs) in 
>this tree would be hard links to the "real" files specified in the mask. 
>Only dirs & files included in the spec are visible. When an instance of 
>fooprocess is started, /bin/fooprocess/metas/mask is automagically mounted 
>as the process's root filesystem. The mask would be the filesystem. 
>Other than the use of the metas reiserism (and mask maintenance wizardry)
>this is not any different than chroot. Since the end result here is
>to be no more secure than chroot, but very much easier to deploy and 
>maintain, is there a reason why this cannot be the case?
>  
>
Well, I had not planned on the hard links in particular---this is where 
the fall
through semantics seem to be correct.  Suppose there are 1000 masks and
a new file gets added are you planning to add 1000 links?

>  
>
>>you can insert a search of the mask tree. If the 
>>search fails, then it is not excluded and the request falls through 
>>to normal VFS handling. In the /etc/passwd case above, it would find 
>>/etc/passwd and so the file is excluded. Processing would stop there, 
>>returning some error. How does this sound? 
>>
>>I don't quite understand this paragraph above.
>>    
>>
>
>
>Probably because I'm not on the same page as you and George.
>Imagine a filesystem with two trees: one, the real
>root filesystem and two, the anti-root tree (exclusions). This
>fs would be the root fs for the process. Let's say fooprocess has 
>the following exclusions:
>
>	/etc/passwd
>	/etc/shadow
>	/var
>
>Above, when I said "insert a search of the mask tree" what I meant was
>"first search the exception [semantic] tree (anti-tree) associated with 
>this process. If you find the object there, then report it as NOT FOUND.
>Otherwise, proceed with a normal fs tree search (fall-through). Basically,
>a dynamic, per-process (er, per mask) hidden attribute. The modified VFS 
>code to store the dentry of the root of the mask base dir, then use 
>normal namei(), etc. path resolution interfaces to see if the file exists 
>in the exception list? IOW, when fooprocess attempts to open /etc/passwd 
>when fooprocess is under the above mask, the following happens: VFS 
>identifies process as being undermask and so knows dentry of the base dir 
>of the exception list (fooprocess/metas/mask). Before doing 'normal' 
>handling, VFS treats this as a request to operate on 
>fooprocess/metas/mask/etc/passwd. If VFS finds the filename, then NOT 
>FOUND is returned. Otherwise, file processing proceeds normally.
>  
>
This is closer to my understanding.

>>George:
>>To give a couple of examples:
>>    1) A given process (say a restricted shell) can not exec() an
>>        executable with the set-uid bit on.
>>         - directly
>>         - indirectly (e.g., via bash)
>>    2) Apache can only create/write files in /var/web/incoming.
>>         - files created or modified can not have any execute bit set 
>>and executing chmod is excluded.
>>
>>Hans:
>>this protection happens while traversing the mask or at the fall through 
>>point.  Hmmm, we need to accumulate a set of permissions that apply to 
>>something that are specific to how we got there.  That could be complex 
>>in the VFS details.  We can defer it to Phase II if necessary.  George, 
>>you should spend a day (not this week) figuring out how much work it 
>>would be to make that work.  It will be the details of it that will be 
>>dangerous....
>>    
>>
>
>I'll tackle scenario #2:
>* Executing chmod would be excluded because it would not be visible in the mask.
>  
>
    Note that, at some point, one would like to disallow chmod() and 
fchmod() in any
    child process---but this is beyond the scope or the current project.

>* "files created or modified can not have any execute bit set" 
>  Implicit in this statement is that, in addition to filtering object 
>  visibility, masks will preempt/proscribe certain fs operations -- in this 
>  case, the setting of certain attributes (i.e. exec bit). If this is correct
>  then what can masks allow/prohibit WRT operations/attributes performed
>  on objects. This is what I was trying to clarify with my earlier question.
>
>  
>
    Let us say that, as this example suggests, it would make the masking 
more
    powerful and more useful since allowing someone on the internee to 
store data
    on your disk is much less risky than allowing them to get a process 
running
    over which they have control.

    That a viable and scalable implementation of this can be developed 
is an open
     question---currently ;-)


[-- Attachment #2: Type: text/html, Size: 9058 bytes --]

Re: viewprinting: what format should views be stored in?

[David Dabbs]

>>>
>>> When did masks specify visibility of files? According to Hans :
>>
>> This is clearcase functionality so everyone assumed it from the original
>> posting http://www.namesys.com/blackbox_security.html
>
>yes.
>
>Trying for clarity in the role of the mask interpreter layer.
>Does the mask act as a gatekeeper - passing things through to the fs 
>(possibly simpler to implement but _far_ less functional)
>Or (more likely) does the mask layer take over the role of authoriser(?) 
>in which case it delegates to the fs for the fs authorisation (attr) and 
>then bitwise ANDs that with it's own masklet (maybe shortcutting if the 
>mask determines the file is invisible)
>
>I think we all agree on the latter but I thought it best to be clear.

This clarity/specificity, at least re. your Phase I, is what I've been trying 
to get a handle on as well. Seems that in order to discuss /how/ to build this feature we should share an understanding of /what/ it is that it will do. This includes user inputs ('constraints' in mask[let] specifications) as well as
side effects or changes to 'normal' process/OS/filesystem operations.

From Hans's original post:

>It will however allow a useful subset of the needed security constraints 
>to be more compactly specified
>
Is there a proposed membership for the "useful subset," or better yet
what security constraints are not useful?

>[viewprinting] is also useful when you want to conveniently manage the 
>set of objects a particular executable is allowed to access without walking 
>the filesystem tree to do it.

"Without walking the filesystem to do it" implies that the view/mask
interpreter is the authorisor. The ultimate implementation may not need 
to walk the fs to determine whether process X can access object Y, but one 
cannot avoid doing so if you want to obtain dentries etc. needed by the VFS.

Hans and George, what did you find lacking in currently-available Linux security
module frameworks such as LIDS or LSM? They provide system function hooks
in which module writers may control object access. LSM-based work is on-going. See 
http://sic.iaik.tugraz.at/Best%20Paper%20Award/2004/LSM_quaritsch_winkler.pdf
for details of their addition of module stacking (multiple policies) and hooks into
the TCP layer. I'm going to read up on these frameworks.

>> What if it [mask] changes between two processes starting?
>> Does the running processes mask change? (cf chmod a file - seems 
>>
>> George: I am disinclined to tackle changing masks on the fly 
>> until I have a compelling story to justify the work.
>
>ok - agreed.

No changes on the fly? How does that square with the following 
from the blackbox_security.html feature description?

>
>We will accomodate these scenarios by creating three special view
>specifications: 
>...
>2. Every access outside some view creates a dialogue with the 
>administrator, in which if he oks it the view specification is amended 
>to allow the access. The administrator is also allowed to ok the access 
>without amending the specification, for the case where close monitoring 
>of some accesses is desired, which will result in his being prompted for 
>every access of that kind until he chooses to amend the specification. 
>...


>>>>
>>>> Hans: Your statement is imprecise. The mask will be checked first, 
>>>> and then iff it falls through we do a normal filesystem traversal.
>>>>   
>>>
>>> It was imprecise because perhaps I had a different vprint concept 
>>> and implementation in mind. Using the creation tool, JAdmin creates 
>>> a mask for fooprocess. The mask would be a directory structure 
>>> rooted at /bin/fooprocess/metas/mask. All files (not dirs) in this 
>>> tree would be hard links to the "real" files specified in the mask. 
>>> Only dirs & files included in the spec are visible. When an instance 
>>> of fooprocess is started, /bin/fooprocess/metas/mask is 
>>> automagically mounted as the process's root filesystem. The mask 
>>> would be the filesystem. Other than the use of the metas reiserism 
>>> (and mask maintenance wizardry)
>>> this is not any different than chroot. Since the end result here is
>>> to be no more secure than chroot, but very much easier to deploy and 
>>> maintain, is there a reason why this cannot be the case?
>>>  
>>>
>> I think the 'thing' at /usr/bin/fooprocess/metas/mask
>> is a semantic expansion of the mask (ie it's like a directory tree 
>> but it doesn't point to files, it just contains lots of masklets).
>> It can be traversed in parallel to the real tree traversal and the 
>> masklets it returns will modify the real results. It is purely 
>> semantic. I've expanded this later.
>>
>> Call it a maskfs?

David, isn't what I described above a maskfs (just not called that?)
Anyway, I believe it [mask layer] should be a real filesystem that does 
(eventually) point to files. Yes, the maskfs would need to store the 
"compact representation of the security constraints." Isn't that stat data? 

Based upon the shorthand in use so far, we'll say a masklet specification 
consists of an object name and some permission flags. Why not build the 
maskfs (as before, a directory tree in an existing reiser4 fs) with an entry 
for each object referenced in the mask. So, starting with the (admittedly poor)
prior example mask; Note that since masks can only deny authorisation but not grant it, any flags in the mask are denials. The following are logical:

     /                    -w-      # default dir perms
     /**                 -wx      # default file perms
     /etc/config.file  --x       # only exec denied, rw depends on fs attrs
     <other dirs/files obtained from the admin's process viewprint>

you would then end up with something like:

# ls -l /usr/local/bin/fooprocess/metas

     mask/                 ?-? ?-? ?-?   #  perms from above ANDed with fs attrs
        metas/
            dirdefault     ??? ??? ???    # whatever was in the mask
            filedefault    ??? ??? ???
        etc/                ?-? ?-? ?-?    # writing prohibited
            config.file     ??- ??- ??-    # cannot execute
        ...

When this 'maskfs' tree is created every explicitly named object from 
the mask is associated/linked to the actual object's inode but the attr 
bits are the real ones ANDed with the masklet's. Processes would be 
chrooted to this dir. When the process wants to write to /etc/config.file 
it simply interacts with the chrooted fs with no changes required in the VFS
layer, yes? Now, say the process wants to read a file that is allowed by 
the masklet but not explicitly included in the mask e.g. /etc/foo.conf. 
The VFS will first resolve etc, then the file foo.conf. The dir plugins we 
configure for this tree will, upon not finding foo in this dir, search the 
real /etc for it. If it exists, it is created in the maskfs tree,
assigned the proper attrs, and finally linked to the real /etc/foo.conf. 
Subsequent requests for /etc/foo are processed directly from the maskfs. 
This is a 'lazy linking' of sorts. 

Changing a mask is as easy as chmod on the file, if it was explicitly
part of the mask when it was created. If it wasn't, simply touching it adds it.
The plugins will check that the file actually exists, read the real object's
attr and mask out anything denied by the default file attrs.

Updating the maskfs when the underlying fs has changed is an issue. 
This is only a concern for fs objects that have been instantiated in
maskfs. An enhanced dnotify might be the way to go, 
http://www.lambda-computing.com/~rudi/dnotify/

Is this feasible/workable?

>>
>> If it hits, what types are there in a masklet?
>> I think:
>> * doesn't exist (file not found)
>> * file attribute mask (eg: prevent any writing)
>> * acl 'mask' (an obvious extension of attr but no longer simple 'AND' 
>> logic)
>> * syscall mask (prevent hardlink and maybe chmod - although see below)
>> * 'umask' (chmod) mask (prevent setting suid or execute bit - but may 
>> allows setting +w and setgid on directories - may extend to acls too)
>
> For proof of concept the first 2 suffice.

If we want to specify permissions for a process irrespective of the uid/gid
executing it wouldn't we just specify explicit rights and ignore the ugo
fs attrs?

Regarding permitting/denying syscalls, chmod, etc. I think we should
look into using LSM modules for this (whenever there is funding for it, of course).

David D.

Re: viewprinting: what format should views be stored in?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On Fri, 20 Aug 2004 07:23:24 -0000, David Dabbs said:

> Hans and George, what did you find lacking in currently-available Linux security
> module frameworks such as LIDS or LSM? They provide system function hooks
> in which module writers may control object access. LSM-based work is on-going. See 
> http://sic.iaik.tugraz.at/Best%20Paper%20Award/2004/LSM_quaritsch_winkler.pdf
> for details of their addition of module stacking (multiple policies) and hooks into
> the TCP layer. I'm going to read up on these frameworks.

Amen to that - while reading through Hans' summary, I was having a hard time
figuring out what this was buying us that SELinux doesn't provide. Thanks for the
pointer to the Quartisch&Winkler paper, as module stacking seems to be heating up.
The "usual scenario" for what people seem to want with LSM is a MAC system
like SELinux or LIDS, then zero or more "pathological case" handlers (for
instance, the 'BSD Securelevels' LSM, or some variant of the OpenWall mods, or
a chroot/jail module) to harden a specific aspect of the system, and then the
Capabilities LSM.

The biggest reason for wanting to do security at the LSM level rather than the
filesystem level is because that way you can *really* secure things (hint -
your filesystem can be as secure as you want, but if you don't also secure
stuff like unix-domain sockets or SYSV shared memory segments, 2 cooperating
processes can end-run an MLS trying to prevent it....)

If there's a specific need that you can't think of how to implement via SELinux
or the low-level LSM calls, please feel free to ask - if the exact nature of
the problem is itself sensitive, I can vector you to people over on the spook
side of the fence who should be able to either help you out or redirect you to
even spookier people.. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: viewprinting: what format should views be stored in?

[George Beshers]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]


The honest answer is that it has been over a year since I looked at the 
SELinux
stuff.  It is on my to-do list to review what's there.

However, modulo that disclaimer, I believe what we are doing can readily 
become
part of a larger strategy, indeed as you point out, it must to truely 
promote security.
This doesn't bother me in the slightest.  I will feel that the time was 
worthwhile if
our implementation becomes a standard part of a larger security 
apparatus, e.g.,
because we proved that file system masks could scale to multi-terabyte 
repositories.

I will take a gander at the paper you reference this weekend.


Valdis.Kletnieks@vt.edu wrote:

>On Fri, 20 Aug 2004 07:23:24 -0000, David Dabbs said:
>
>  
>
>>Hans and George, what did you find lacking in currently-available Linux security
>>module frameworks such as LIDS or LSM? They provide system function hooks
>>in which module writers may control object access. LSM-based work is on-going. See 
>>http://sic.iaik.tugraz.at/Best%20Paper%20Award/2004/LSM_quaritsch_winkler.pdf
>>for details of their addition of module stacking (multiple policies) and hooks into
>>the TCP layer. I'm going to read up on these frameworks.
>>    
>>
>
>Amen to that - while reading through Hans' summary, I was having a hard time
>figuring out what this was buying us that SELinux doesn't provide. Thanks for the
>pointer to the Quartisch&Winkler paper, as module stacking seems to be heating up.
>The "usual scenario" for what people seem to want with LSM is a MAC system
>like SELinux or LIDS, then zero or more "pathological case" handlers (for
>instance, the 'BSD Securelevels' LSM, or some variant of the OpenWall mods, or
>a chroot/jail module) to harden a specific aspect of the system, and then the
>Capabilities LSM.
>
>The biggest reason for wanting to do security at the LSM level rather than the
>filesystem level is because that way you can *really* secure things (hint -
>your filesystem can be as secure as you want, but if you don't also secure
>stuff like unix-domain sockets or SYSV shared memory segments, 2 cooperating
>processes can end-run an MLS trying to prevent it....)
>
>If there's a specific need that you can't think of how to implement via SELinux
>or the low-level LSM calls, please feel free to ask - if the exact nature of
>the problem is itself sensitive, I can vector you to people over on the spook
>side of the fence who should be able to either help you out or redirect you to
>even spookier people.. ;)
>
>  
>

[-- Attachment #2: Type: text/html, Size: 3170 bytes --]

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

We only do filesystem isolation because that is our specialty, 
filesystems, and it is better to do less well.

We fundamentally differ from other approaches because I don't think the 
problem is in developing tools to allow people to fine grain security if 
they take the time to do it, I think the problem is that nobody has the 
time to specify fine grained security for the executables on their 
computers, and our focus is on the filesystem aspects of automating the 
specification of the fine grained security for an executable.  
Researchers after us can generalize our approach to things outside the 
filesystem namespace, or, better, put those things into the filesystem 
namespace.;-)

Re: viewprinting: what format should views be stored in?

[David Dabbs]

>| David Greaves wrote:
>
>Hans Reiser wrote:
>
>| David Greaves wrote:
>|
>|>
>|> David
>|> PS can I offer 'mask specification' (shortened to maskspec above)
>> instead of 'presentation mask' for the glossary.
>|>
>|>
>|> Glossary? of?
>
>terms.
>There have been occasional mails that try and clarify what we're
>talking about. I think they're helpful.

Definitely. We'll be able to meaningfully discuss implementing if we share
the same concepts for requirements/functionality. Naturally, consistent terminology for these concepts should be helpful for us as well as anyone else 
joiing in sometime later.
 
>Confusion is bad.

Certainly a time waster.


DavidD

Re: viewprinting: what format should views be stored in?

[David Dabbs]

George Beshers wrote:
>The honest answer is that it has been over a year since I looked at the
>SELinux stuff.  It is on my to-do list to review what's there.
>
>However, modulo that disclaimer, I believe what we are doing can 
>readily become part of a larger strategy, indeed as you point out, it 
>must to truely promote security. This doesn't bother me in the 
> slightest.  I will feel that the time was worthwhile if our 
> implementation becomes a standard part of a larger security
>apparatus, e.g., because we proved that file system masks could 
>scale to multi-terabyte repositories.
>
>I will take a gander at the paper you reference this weekend.
>
>
>Valdis.Kletnieks@vt.edu wrote:
>
>On Fri, 20 Aug 2004 07:23:24 -0000, David Dabbs said:
>
>>Hans and George, what did you find lacking in currently-available Linux
>>security module frameworks such as LIDS or LSM? They provide system
>>function hooks in which module writers may control object access. 
>>LSM-based work is on-going. See http://sic.iaik.tugraz.at/Best%20Paper
>>%20Award/2004/LSM_quaritsch_winkler.pdf for details of their addition 
>>of module stacking (multiple policies) and hooks into the TCP layer. 
>>I'm going to read up on these frameworks.
>>    
>>
>Amen to that - while reading through Hans' summary, I was having a 
>hard time figuring out what this was buying us that SELinux doesn't 
>provide. Thanks for the pointer to the Quartisch&Winkler paper, as 
>module stacking seems to be heating up.


We should also review the following LSM-based project from IBM
presented at Usenix 2004. 

http://www.usenix.org/events/usenix04/tech/freenix/rahimi.html

While I'm not familiar with the OpenBSD "Trusted Path Execution" concept, controlling trusted/untrusted applications figured centrally in Hans's original proposal. In addition, the abstract mentions a "pseudo-filesystem" and this sounds similar to what has been under consideration here.

DavidD

 

Trusted Path Execution for the Linux 2.6 Kernel as a Linux Security Module 
Niki A. Rahimi, IBM 

Abstract
The prevention of damage caused to a system via malicious executables is a significant issue in the current state of security on Linux operating systems. Several approaches are available to solve such a problem at the application level of a system but very few are actually implemented into the kernel. The Linux Security Module project was aimed at applying security to the Linux kernel without imposing on the system. It performs this task by creating modules that could be loaded and unloaded onto the system on the fly and according to how the administrator would like to lock down their system. 
The Trusted Path Execution (TPE) project was ported to the Linux kernel as a Linux Security Module (LSM) to create a barrier against such security issues from occurring. This paper will attempt to explain how Trusted Path Execution is implemented in the Linux kernel as an LSM. It will also describe how TPE can prevent the running of malicious code on a Linux system via a strategically placed hook in the kernel. The usage of a pseudo-filesystem approach to creating an access control list for users on the system will also be discussed. The paper will further explain how TPE is designed and implemented in the kernel. This paper will show how the access control list is utilized by the module to place checks on the execution of code on the system along with a check of the path the code is being run in. Further, the origins of the "Trusted Path" concept and its origination in the OpenBSD operating system will be discussed along with how TPE was introduced to the Linux security community. The paper will conclude with a synopsis of the contents and future paths and goals of the project. 

Re: viewprinting: what format should views be stored in?

[David Dabbs]

>Hans Reiser wrote:
>We only do filesystem isolation because that is our specialty, 
>filesystems, and it is better to do less well.
>
>We fundamentally differ from other approaches because I don't think the 
>problem is in developing tools to allow people to fine grain security if 
>they take the time to do it, I think the problem is that nobody has the 
>time to specify fine grained security for the executables on their 
>computers, and our focus is on the filesystem aspects of automating the 
>specification of the fine grained security for an executable.  
>Researchers after us can generalize our approach to things outside the 
>filesystem namespace, or, better, put those things into the filesystem 
>namespace.;-)

Sounds like your approach will differ a) in scope, in that you are only concerned with securing filesystem access and b) in that you will provide "wizards" where the other approaches provide none or the ones they provide suck. If this is the case, then why are we talking about mask interpreters and how they will moderate file access? Why aren't we focusing on your "sweet spot"; the wizards that assist the clueless/lazy/overworked admin in profiling a process in order to create and maintain the viewprint/mask?

If your ultimate concern is truly in providing tools that make it easy to deploy
comprehensive security, then it seems the approach to take is to contribute wizards/whatever that make implementing your process-oriented fs security vision incredibly simple under LSM or other framework. If you're only going to focus on your metier, filesystems, and exclusively on your own filesystem, at least contribute something that doesn't reinvent any wheels and which "plays well with others." People do need to secure more than the filesystem. Reiser4's adoption curve would seem to benefit if people can implement advanced filesystem security and also use the same framework to secure other aspects.  


David

Re: viewprinting: what format should views be stored in?

[Hans Reiser]

The LSM paper cited (that does not require paying money) says very 
little about what they do with regards to the filesystem.  Do you have a 
more informative URL?

Re: viewprinting: what format should views be stored in?

[David Dabbs]

>Hans Reiser wrote:
>The LSM paper cited (that does not require paying money) says very 
>little about what they do with regards to the filesystem.  Do you have a 
>more informative URL?
>

Okay. Here's what I found with a few clicks in Google. None of these will describe exactly what you want to do. AFAIKS none are process-oriented, but LSM probably provides much of the foundation needed to get where you want to go.

David


Here's what appears to be a free version of the TPE paper. The reference to "pseudo filesystem" meant the sysfs interface.
http://oss.software.ibm.com/linux/presentations/usenixtech2004/tpepaper.pdf

Sept 2004 SysAdmin mag article about implementing BSD Secure Levels in LSM
* http://www.samag.com/documents/s=9304/sam0409a/0409a.htm

LSM Docs (kernel 2.5 interface, still uses sys_security)
* http://lsm.immunix.org/docs/2.5/lsm_interface.html
* http://lsm.immunix.org/lsm_modules.html

LSM List Archive
* http://mail.wirex.com/pipermail/linux-security-module/2004-August/date.html

File operations controls from the SELinux docs. SEL is LSM-based.
* http://www.nsa.gov/selinux/papers/freenix01/node9.html

"Advances in Linux Security: The Linux Security Modules Project".
Talk given at August 2003 SecureWorld conference.
http://oss.software.ibm.com/linux/presentations/secureworld2003/P14-LSM.pdf
  
LIDS home
* http://www.lids.org/

LIDS faq: protecting files
* http://www.lids.org/lids-faq/lids-faq.html#CONFIGURING-LIDS

Re: viewprinting: what format should views be stored in?

[David Dabbs]

>
>The LSM paper cited (that does not require paying money) says very 
>little about what they do with regards to the filesystem.  Do you have a 
>more informative URL?
>

Here's a concrete example of an LSM directory jail implementation. Not all the features I think you're aiming for but it is source and is indicative of what is possible (er, has already been done) with LSM.

David



http://lwn.net/Articles/57713/

From:   "Serge E. Hallyn" <hallyn@CS.WM.EDU> 
To:   linux-security-module@wirex.com 
Subject:   dirjail module 
Date:   Mon, 10 Nov 2003 23:42:26 -0500 


Attached are the header comments for a new LSM.  I wrote it a few
months ago to address a particular need in a large-scale installation
for which DTE would have been inefficient.  The module source can be
found at http://www.cs.wm.edu/~hallyn/dirjail.c.

I'll be curious to see if anyone else sees any use for this.

-serge

/*
 * File: dirjail.c
 *
 * Description: Intended as an efficient prison for suspect child processes.
 *
 *  Assume a large set of users.  Each has a directory under, say,
 *  /home/sxx/username, where xx is a number from 00-03, and username
 *  is the account name.  Their files may be served and processed by
 *  system processes and scripts (apache, accounting, etc).  However,
 *  they may also, under /home/sxx/username, place their own scripts.  You
 *  wish to confine the scripts to MOSTLY access only /home/sxx/username.
 *
 *  modprobe dirjail
 *  for count in 00 01 02 03; do
 *    echo -n /home/s$count > /proc/jails
 *  done
 *  echo -n /bin > /proc/exec_exceptions
 *  echo -n /lib > /proc/exec_exceptions
 *  echo -n /tmp > /proc/rw_exceptions
 *  echo -n /proc > /proc/read_exceptions
 *
 *  Now a script started from under /home/s01/user3 will be confined to
 *  only read, write, and execute files under /home/s01/user3.  Exceptions
 *  to this are:
 *    it may execute anything under /bin
 *    it may read and write under /tmp
 *    it may read under /proc
 *
 *  For the sake of simplicity, directory rx is always allowed.
 *  However, directory write and file rwx are restricted.
 *
 *  Any children of said process will be convined to the same jail.
 *
 * Copyright (C) 2001 Serge E. Hallyn <hallyn@cs.wm.edu>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 */