david@lang.hm wrote on 18/08/2008 18:02:57:

quoted text
> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:
> 
> > david@lang.hm wrote on 18/08/2008 13:07:47:
> >
> >>>> 3. have a kernel mechanism to say "set this namespace tag if this
> > other
> >>>> namespace tag is set" (this allows a scanner to set a 'scanning' 
tag
quoted text
> >>> when it
> >>>> starts and only set the 'blessed' tag if the file was not dirtied
> >>>> while it was
> >>>> being scanned. without this there is a race condition that could
> > cause a
> >>> file
> >>>> to be marked as good incorrectly, the initial threat model ruled
> >>> outworrying
> >>>> about race conditions, but this seems like a fairly easy one to 
close
quoted text
> >>>
> >>> I don't think you can use xattrs as some atomic barriers, I suspect
> > they
> >>> are suspectible to same race conditions as open-write-read.
> >>
> >> this is why it would require kernel support to turn them into atomic
> >> barriers (and the reason for this item). without kernel support there 
is
quoted text
> > a
> >> race (it's debatable if that race i significant enough to require the
> >> implementation of kernel support to close it, but that's why I listed
> >> this)
> >
> > Maybe not since there are races with database updates anyway. What 
would
quoted text
> > be necessary is a method of clearing the whole xattr namespace on 
fresh
quoted text
> > mount to avoid trusting stale data. That I so far don't see how it can 
be
quoted text
> > done from userspace safely.
> 
> you don't need to clear the xattr space, you can get the same effect by 
> having scanners that care increment their generation ID.

Not the most efficient way since generation ID is global while we are 
talking about a single mount/filesystem. So incrementing the generation ID 
causes all filsystems to be rescanned. Also you need additional hooking in 
mount, plus you have a race condition unless you block in mount while you 
do your stuff. And you need to take care about deadlocks.
 
quoted text
> but this would require some way for them to learn of mounts.
> 
> > Also problem with read-only mounts comes to mind. Ups, yes, this is a 
big
quoted text
> > problem with this scheme in general. We cannot trust xattr namespace 
when
quoted text
> > we mount something fresh because it has been potentialy mounted on a
> > different system, but if it gets mounted read-only we cannot purge 
that
quoted text
> > data and we cannot store our scan results. Only option is not to do 
any
quoted text
> > scanning.
> >
> > This may not be a common usage scenario so it may not be a problem 
though.
quoted text
> 
> this is also a policy question, you may _want_ to trust the scanning 
done 
quoted text
> by a different machine, so it's not always the case that you need to 
> invalidate the scan results when mounting things.

Without additional filesystem/VFS support you won't be able to tell if 
wherever the filesystem was previously mounted had any scanning done. It 
may have been mounted on a kernel which does not support the whole scheme 
so it didn't clear the namespace for modified files.
 
quoted text
> >> I don't think this tool should require the use of other tools to 
exempt
quoted text
> >> programs from it, and going that way lies madness (there are too many
> >> combinations of different tools, trying to define all of the possible
> >> interactions can't work, and saying that you must use SELinux with 
this
quoted text
> >> and not any of the other options is going to be a sure way to get a 
lot
quoted text
> > of
> >> people to not use your tools)
> >
> > Then there is still a question of who allows some binary to declare 
itself
quoted text
> > exempt. If that decision was a mistake, or it gets compromised 
security
quoted text
> > will be off. A very powerful mechanism which must not be easily
> > accessible.  With a good cache your worries go away even without a 
scheme
quoted text
> > like this.
> 
> I disagree. I think the number of binaries on the system that don't need 

quoted text
> the scanning is surprisingly large, many programs just treat files they 
> access as blobs of data and don't try to interpret them. it's only when 
> the file is interpreted or handed to another system that it needs to be 
> scanned.

In a way this is a slighlty different way of moving protection from core 
to the border which means you must enumerate all possible entry/exit 
points and you must not get it wrong.
 
quoted text
> >>> I think you overcomplicated it both in design and in presentation of
> > this
> >>> text. I was not able to follow and absorb all your postings so I am
> > not
> >>> sure what apart from single cache point and non-persistent cache you
> >>> dislike in Eric's proposal?
> >>
> >> single cache point, non-persistant cache, inablility to support 
scanners
quoted text
> >
> >> that don't involve enforcement, inability to do preemptive scanning 
of
quoted text
> >> changes, inability to have user policy define what priority to put on
> >> checks, lack of thought of any use other then anti-virus functions.
> >
> > So you do have a whole new set of requirements which if agreed on 
someone
quoted text
> > will need to implement.

You skipped this bit where I almost asked you if you are willing to get 
your hands dirty with implementing all this? :)

quoted text
> >> yes this is more complicated than a single bit in memory as the flag,
> > but
> >> it's also far more flexible.
> >
> > True. It would be nice though if we could think of a solution which 
would
quoted text
> > not have a in-kernel tag parser. I am mostly worried about performance
> > because tags would have to be checked on every open/read/whetever and
> > compared against the policy set from userspace. If I understand 
correctly
quoted text
> > how you imagined it. Or if you wanted to go to userspace for all these
> > decisions then add even more cost for context switching. In later case 
you
quoted text
> > would also have some kenrel code dealing with cleaning xattr tags 
which
quoted text
> > would not be mentioned anywhere else in the kernel and that sounds a 
bit
quoted text
> > like black magic.
> 
> I don't have an in-kernel tag parser. I have a in-kernel tag clearer, 
but 
quoted text
> the tag parser is in the userspace library. this also avoids all the 
> context switches that worry you as well.

How is that? Context switches which worry me are the ones which happen 
when for each access to a file we need to go to userspace just to see if 
it has already been scanned. That is why I was more in favour completely 
of in-kernel caching scheme.
 
quoted text
> >>>> are any of the features I list impossible to implement?
> >>>
> >>> Serialisation and race condition avoidance using extended attributes 
I
quoted text
> >>> think.
> >>
> >> why could the kernel not have a command that locked the inode for the
> >> read, check, write cycle of changing extended attributes? I agree 
(and
quoted text
> >> document) that without such support there is a race condition.
> >
> > We could but I agree that we probably don't need to. Having this would 
be
quoted text
> > very bad for performance.
> 
> why would this be bad for performance? the atomic version would be a 
> different function that would only be used when marking a file clean, 
and 
quoted text
> as this locking would only be contended if multiple scanners needed to 
> mark a file clean at the same instance, it will be a very 
low-contention, 
quoted text
> low-use lock.

Maybe you would need to lock when checking if file is clean to avoid 
races? Don't know, I didn't give this that much thought.

--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos

"Views and opinions expressed in this email are strictly those of the 
author.
 The contents has not been reviewed or approved by Sophos."
 

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

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