[redhat-lspp] Comments on Pam-Namspace

[Janak Desai]

Daniel J Walsh wrote:

> Janak Desai wrote:
>
>> Daniel J Walsh wrote:
>>
>>> I now have pam_namespace working with MLS policy, for the /tmp and 
>>> /var/tmp directory
>>>
>>> We need to change the namespace.conf file to be
>>>
>>> /tmp /tmp/.inst-$USER-   both root,adm
>>> /var/tmp/.inst-$USER-   both root,adm
>>> #$HOME $HOME/.inst-      context
>>>
>>> Why have the first two commented out?  I think you put pam_namespace 
>>> in the /etc/pam.d file you get /tmp and /var/tmp automatically.
>>>
>> Ok, I will change the conf file accordingly.
>>
>>> Also by default for the instance directory should be a subdirectory 
>>> of the parent.
>>
>>
>> Agreed. I will update the config file and the README appropriately.
>>
>>>
>>> As far as the polyinstantiation of the home dir.  Shouldn't this 
>>> only happen on none SystemLow contexts?
>>>
>>> I turned it on and my homedir disappeared which seems strange.
>>>
>> This is under the control of the policy. The namespace module calls 
>> security_compute_member library
>> function and expects the policy to return appropriate member 
>> directory context. This member directory
>> context is then used for instance directory.
>
> But how do we in policy tell it to do nothing?

The current implementation always creates an instance directory, even if 
the context returned by the
security_compute_member() returns the same context as that of the 
directory to polyinstantiate. By "do
nothing" do you mean that we should not create an instance if the 
security_compute_member() returns
the same context as the directory to polyinstantiate? It makes sense to 
add that optimization. I will add
that to my list of things to do.

-Janak

>>
>>> Why do we still use the MD5sum for the directory name.  Why not just 
>>> use the level?  Would make it easier to figure out what is going on.
>>>
>> I was using MD5 hashes to try and obscure the directory name. 
>> However, now that I know that if
>> someone really wants to figure out the context, they can, even if the 
>> name is hashed. So I can
>> remove the use of hash or make it configurable (if anyone still sees 
>> any benefit of using it).
>>
>> Will make these changes after I return from the symposium ..
>>
>> -Janak
>>
>
> -- 
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
>