Messages in this thread | | | Date | Fri, 02 Jan 2009 19:39:48 -0800 | From | "Justin P. Mattock" <> | 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
| |