Message-ID: <495EDE04.5080703@gmail.com>
Date:	Fri, 02 Jan 2009 19:39:48 -0800
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Daniel Phillips <phillips@...nq.net>
CC:	tux3@...3.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Tux3] Tux3 report: A Golden Copy

Daniel Phillips wrote:
> On Friday 02 January 2009 17:32, Justin P. Mattock wrote:
>   
>> Daniel Phillips wrote:
>>     
>>> On Friday 02 January 2009 15:11, Justin P. Mattock wrote:
>>>   
>>>       
>>>> The game that came to mind when I first
>>>> heard of tux3(I had to google a bit to find the name)
>>>> was tux racer.  :^)
>>>> quick question:
>>>> what is the state for security file labeling for
>>>> SELinux on this filesystem?
>>>>         
>>> There is a lot of interest in security labels.  You are not the first
>>> to ask.
>>>
>>> Tux3 variable inode attributes are ideal for implementing security 
>>> labels efficiently, way more lightweight than extended attributes.  
>>> Otherwise, we would like to know exactly what people want.
>>>
>>> Regards,
>>>
>>> Daniel
>>>   
>>>       
>> thats probably one of the main areas of
>> interest that I have in filesystems,
>> the ability to run a policy etc..
>> As for what people want, thats tough
>> to say, my guess would be file corruption,
>> then probably security etc..
>>     
>
> I meant, what do people specifically want in security.  For SELinux,
> probably the most important issue is efficient extended attribute
> support, which Tux3 has a pretty good start on:
>
>    http://lwn.net/Articles/300416/
>    Tux3 gets a high speed atom smasher
>
>   
Thats some crazy stuff!! and just think most of it is
simply magnets.(but more complicated than that)
> One feature we are kicking around to make life easier for SELinux:
> sometimes the filesystem can run while SELinux is not running, and
> security labels will be wrong when SELinux re-enters the picture.  We
> have in mind to provide a persistent log of filesystem events that the
> security system can attach to on startup and find out what went on in
> its absence.
>
>   
That sounds nice:

find out what went on in
its absence.

> And it might be nice to provide direct access to Tux3's variable inode
> attributes as I mentioned, letting the security system bypass the
> heavyweight xattr paths.  My thinking is, the more direct the security
> path, the more likely it is to be secure, and the less overhead it has,
> the more likely people are to use it.  Somebody might want to play with
> this idea and see if it makes a difference.
That makes sense:

the more direct the security
path, the more likely it is to be secure, and the less overhead it has,

> Of course, these features are secondary to base filesystem solidity,
> which will be the main focus for the next little while, but now is the
> time to talk about what you want, in case the design can be adjusted to
> make it more practical.
>
> More security wishes go here: ->[___________________]<-
>
> Regards,
>
> Daniel
>
>   

I guess the most simplest wish would to make sure that tux3
does support SELinux, this way people have more options,
to work with.(Then worry about everything else later);
 One of the main problems I have with osx and winxp
is the missing of such options(I feel naked without SELinux);

regards;

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists