First of all, it's not always a good idea to make a defensive copy. You only want to do that with mutable classes that cannot enforce the contract that your business logic requires (such as collections).
Yours is a perfect example. FilenameFilter is immutable--nothing can change it through that interface. Feel free to pass it around at will. The only potential problem is threading, and that's pretty rarely a problem.
The more general solution (For classes that are actually an issue like collections) would be to wrap the collection in a class rather than copy it. If you wrap it in a business logic class, you can restrict access until you are sure it won't break your business logic rules, then feel free to pass it everywhere.
You'll notice that the JDK pretty much never passes collections. This is on purpose, and the exact reason for the "Copying" pattern you are considering. Usually the JDK will pass an array, and most collections have a fairly easy way to generate a copy of their contents to pass on.
Copying an object is actually extremely rare--collections and arrays are the primary ones to be concerned with. Most other objects can defend themselves pretty well if they are even half-decently designed.