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

["David Dabbs" <david@dabbs.net>]

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.