headers
Daniel Phillips | 3 Jan 02:19

Re: Tux3 report: A Golden Copy

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
Permalink | Reply |
headers
Justin P. Mattock | 3 Jan 02:32
Picon

Re: Tux3 report: A Golden Copy

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..
(Continue reading)

Permalink | Reply |
headers
Daniel Phillips | 3 Jan 04:03

Re: [Tux3] Tux3 report: A Golden Copy

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,
(Continue reading)

Permalink | Reply |
headers
Justin P. Mattock | 3 Jan 04:39
Picon

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..
(Continue reading)

Permalink | Reply |
headers
Jamie Lokier | 4 Jan 04:17

Re: [Tux3] Tux3 report: A Golden Copy

Justin P. Mattock wrote:
> 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.

That sounds like a feature Windows had for many years now, (since
Windows 2000?).  It complements the Windows equivlant of
dnotify/inotify/fsnotify.

It's used for file indexing too (think equivalent to Spotlight,
Beagle, etc.), and other types of security scanning (think equivalent
to Tripwire).

I wonder why the people writing file indexing tools for Linux never
made a fuss about this.  Inotify is ok for indexing, but means quite a
few minutes of intensive disk activity after each boot to rescan /home.

-- Jamie
--
(Continue reading)

Permalink | Reply |
headers
Theodore Tso | 4 Jan 14:04
Picon
Picon
Favicon
Gravatar

Re: [Tux3] Tux3 report: A Golden Copy

On Sun, Jan 04, 2009 at 03:17:33AM +0000, Jamie Lokier wrote:
> Justin P. Mattock wrote:
> > >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 like a feature Windows had for many years now, (since
> Windows 2000?).  It complements the Windows equivlant of
> dnotify/inotify/fsnotify.

Arguably you want to do this in the VFS layer, not in the low-level
filesystem level if you want most applications to adopt it.

> It's used for file indexing too (think equivalent to Spotlight,
> Beagle, etc.), and other types of security scanning (think equivalent
> to Tripwire).

Eric Paris has a patch he's been proposing for a while now for a new
notify mechanism designed for anti-virus scanners...

						- Ted
Permalink | Reply |
headers
Daniel Phillips | 5 Jan 02:10

Re: [Tux3] Tux3 report: A Golden Copy

Hi Ted,

On Sunday 04 January 2009 05:04, Theodore Tso wrote:
> On Sun, Jan 04, 2009 at 03:17:33AM +0000, Jamie Lokier wrote:
> > Justin P. Mattock wrote:
> > > >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 like a feature Windows had for many years now, (since
> > Windows 2000?).  It complements the Windows equivlant of
> > dnotify/inotify/fsnotify.
> 
> Arguably you want to do this in the VFS layer, not in the low-level
> filesystem level if you want most applications to adopt it.

It has to be generic all right, but the VFS is not able to do the job
on its own.  To be useful for indexing, the reported events must
already be persistently recorded, and the VFS has no idea about when
that happens.  The filesystem is the expert on that subject, and it
must generate the events.  I can't imagine a reasonable VFS-level
emulation, or what value the VFS would add by acting as middleman for
a stream of filesystem events.

The natural way to do this is for the filesystem to stream events
directly to the monitoring application over a pipe-like fd.  Maybe a
library for event delivery could be shared by filesystems, to impose
(Continue reading)

Permalink | Reply |
headers
Jamie Lokier | 5 Jan 03:13

Re: [Tux3] Tux3 report: A Golden Copy

Daniel Phillips wrote:
> > Arguably you want to do this in the VFS layer, not in the low-level
> > filesystem level if you want most applications to adopt it.
> 
> It has to be generic all right, but the VFS is not able to do the job
> on its own.  To be useful for indexing, the reported events must
> already be persistently recorded, and the VFS has no idea about when
> that happens.  The filesystem is the expert on that subject, and it
> must generate the events.  I can't imagine a reasonable VFS-level
> emulation, or what value the VFS would add by acting as middleman for
> a stream of filesystem events.

The VFS does have a some helpful generic support for quotas, although
it also requires filesystem-specific help.  This is quite similar.

I see what you mean about knowing when an event reaches _persistent_
storage.  To be accurate, the event log must be folded into the
filesystem's transaction/commit model (including right use of barriers
etc.), and during journal/equivalent recovery, and fsck repair, the
event log must err on the side of too many rather than too few events.
(Or have a "rescan everything needed" event.)

An event log does not have to be _entirely_ accurate to be useful for
things like security scanning and indexing.  It is enough that it errs
on the side of recording a few too many, causing a few more app level
checks.

On the other hand, when used for an audit trail, you never want extra
events to be logged.
(Continue reading)

Permalink | Reply |
headers
Daniel Phillips | 8 Jan 03:50

Re: [Tux3] Tux3 report: A Golden Copy

Hi Jamie,

On Sunday 04 January 2009 18:13, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > > Arguably you want to do this in the VFS layer, not in the low-level
> > > filesystem level if you want most applications to adopt it.
> > 
> > It has to be generic all right, but the VFS is not able to do the job
> > on its own.  To be useful for indexing, the reported events must
> > already be persistently recorded, and the VFS has no idea about when
> > that happens.  The filesystem is the expert on that subject, and it
> > must generate the events.  I can't imagine a reasonable VFS-level
> > emulation, or what value the VFS would add by acting as middleman for
> > a stream of filesystem events.
> 
> The VFS does have a some helpful generic support for quotas, although
> it also requires filesystem-specific help.  This is quite similar.

If the VFS stored the index on the filesystem then it would be similar,
but I don't think anybody will like the idea of the VFS operating an
indexer in-kernel.  Given that the indexer is maintained by user space,
the kernel's job is just to deliver the events the user space indexer
needs, which is a very different activity pattern from the generic quota
file scheme.

> I see what you mean about knowing when an event reaches _persistent_
> storage.  To be accurate, the event log must be folded into the
> filesystem's transaction/commit model (including right use of barriers
> etc.), and during journal/equivalent recovery, and fsck repair, the
> event log must err on the side of too many rather than too few events.
(Continue reading)

Permalink | Reply |
headers
Evgeniy Polyakov | 8 Jan 05:38
Favicon

Re: [Tux3] Tux3 report: A Golden Copy

Hi Daniel.

On Wed, Jan 07, 2009 at 06:50:59PM -0800, Daniel Phillips (phillips <at> phunq.net) wrote:
> Suppose a file delete event is sent, the external indexer dutifully
> deletes its index entry for the file, then the machine crashes without
> completing the delete transaction.  On reboot, the file still exists
> but it has leaked from the index.  Ideas?

Sending delete event when delete is completed?

> > There was an extension to inotify posted a few months ago to do this.
> > Additional events when something becomes persistent.
> 
> Do you have a pointer?

Somthing like that
http://lkml.org/lkml/2008/11/25/272

As of VFS s file-system indexer: what if vfs could provide an interface
to the lower-level FS to get the event flow which could be used by the
userspace the same way it reads the file, and if no such operation is
upported by the filesystem falback to the whole dir rescan...

--

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply |
headers
Justin P. Mattock | 4 Jan 05:29
Picon

Re: [Tux3] Tux3 report: A Golden Copy

Jamie Lokier wrote:
> Justin P. Mattock wrote:
>   
>> 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.
>>     
>
> That sounds like a feature Windows had for many years now, (since
> Windows 2000?).  It complements the Windows equivlant of
> dnotify/inotify/fsnotify.
>
> It's used for file indexing too (think equivalent to Spotlight,
> Beagle, etc.), and other types of security scanning (think equivalent
> to Tripwire).
>
> I wonder why the people writing file indexing tools for Linux never
(Continue reading)

Permalink | Reply |
headers
Daniel Phillips | 4 Jan 05:15

Re: [Tux3] Tux3 report: A Golden Copy

On Saturday 03 January 2009 19:17, Jamie Lokier wrote:
> Justin P. Mattock wrote:
> > 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.
> 
> That sounds like a feature Windows had for many years now, (since
> Windows 2000?).  It complements the Windows equivlant of
> dnotify/inotify/fsnotify.
> 
> It's used for file indexing too (think equivalent to Spotlight,
> Beagle, etc.), and other types of security scanning (think equivalent
> to Tripwire).
> 
> I wonder why the people writing file indexing tools for Linux never
> made a fuss about this.  Inotify is ok for indexing, but means quite a
> few minutes of intensive disk activity after each boot to rescan /home.

Actually they did.  It was a poke from Jos van den Oever, the Strigi
(Continue reading)

Permalink | Reply |

Gmane