Re: [Tux3] Tux3 report: A Golden Copy

[Justin P. Mattock]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/