lkml.org 
[lkml]   [2009]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-01-03 04:43    [W:0.648 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site