headers
John Ogness | 4 Apr 2005 10:17
Picon

Re: 2.1.0-pre3 posted

Tikka, Sami wrote:
> I don't like it much but I suppose I can live with it. It means I will have
> to either introduce a new communications channel between the dazuko
> application and the scanner daemon or extend the scanner protocol. 
> 
> I have to admit I am starting to consider whether it would make everyone's
> life easier at the end of the day if I just integrated the dazuko application
> and scanner daemon into one process. 
> 
> I know my boss won't like either of them one bit because they mean
> significant change with no added benefit to the customers. But if that's the
> way it is going to be then that's the way it is going to be.

Hi,

I don't understand your attitude. If you have better suggestions, I am open 
for them. The entire Trusted Application Framework was orginally developed 
because your company needed this feature! Don't complain, make a good 
suggestion! Until 2.1.0 is officially released, the new interface can still 
be changed. But please do not expect unsafe or platform-specific changes to 
the Dazuko interface.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 2 comments |
headers
Frantisek Hrbata | 5 Apr 2005 15:40
Picon
Favicon

dazukoFS - redirFS

Hi,

I have spent last few weeks trying to find the best way how to implement
dazukoFS (how to catch proper VFS events needed for on-access scanning).
One way is to use the FiST generator for transparent file systems. FiST
creates whole file system by duplicating VFS objects (super block, dentry,
inode, file) and linking them with objects in the lower layer (native file
system or other transparent file system). Because creating almost the
whole file system only to catch some VFS events is too much effort and
waste of time, I started to play directly with VFS object's operations.

The idea is to replace operations of existing or newly created VFS objects
in the given file system subtree. This solution has the following
advantages:

1) No VFS objects duplication is needed.
2) Only VFS objects for given subtree are affected.
3) Only selected functions of VFS objects are redirected.

As a proof of concept I am attaching LKM, which incorporates the points
above.

Here are some module restrictions:
- only one directory can be selected and you have to set it in source
  code (REDIRFS_PATH macro)
- it ignores sub-mounts (works only over one file system)
- only directory and regular file operations are modified
- it just prints EXEC, OPEN and CLOSE events with dentry name
- for now I tested it only on Linux kernel 2.6.11.3, but it should work
  for all 2.6.x kernels. With little modification (locking) it will work
(Continue reading)

Permalink | Reply | 2 comments |
headers
Patrick Bihan-Faou | 5 Apr 2005 17:13

RE: dazukoFS - redirFS

Hi,

> I have spent last few weeks trying to find the best way how to implement
> dazukoFS (how to catch proper VFS events needed for on-access scanning).
> One way is to use the FiST generator for transparent file systems. FiST
> creates whole file system by duplicating VFS objects (super block, dentry,
> inode, file) and linking them with objects in the lower layer (native file
> system or other transparent file system). Because creating almost the
> whole file system only to catch some VFS events is too much effort and
> waste of time, I started to play directly with VFS object's operations.

This is interesting, but to me the greatest interest of the VFS approach
using FiST was to benefit from the portability of FiST beyond just Linux.

How do you plan on supporting OS like Solaris or FreeBSD with this code ? It
does sound like a duplication of effort, but I may be mistaken.

>From a few of the paper that I read on the subject, I don't think that the
processing overhead introduced by the extra work FiST does is really a
problem.

Any thoughts ?

Patrick.
Permalink | Reply | 1 comment |
headers
Frantisek Hrbata | 5 Apr 2005 18:37
Picon
Favicon

RE: dazukoFS - redirFS


>This is interesting, but to me the greatest interest of the VFS approach
>using FiST was to benefit from the portability of FiST beyond just Linux.

>How do you plan on supporting OS like Solaris or FreeBSD with this code ?
>It does sound like a duplication of effort, but I may be mistaken.

You are absolutely right. The solution, as I introduced it, is for Linux
kernels only, because it works directly with Linux VFS internals. It is
intended to solve some Dazuko's problems on Linux kernels (for
example ON-CLOSE events for Linux 2.6).
I am not planning to port this to Solaris or FreeBSD. For these OS
it will have to be completely rewritten.

Actually at this moment I am waiting for some feedback and then we will
see if this is a right way.

>From a few of the paper that I read on the subject, I don't think that
>the processing overhead introduced by the extra work FiST does is really
>a problem.

I think, that processing overhead is not a problem, but the duplication of
VFS objects could be. Please note, that for on-access scanning only some
events like open, exec and close are needed. So, why to duplicate all VFS
objects in the inode and dentry cache.

Franta
Permalink | Reply | 501 comments |
headers
John Ogness | 5 Apr 2005 21:43
Picon

Re: dazukoFS - redirFS

Patrick Bihan-Faou wrote:
>>I have spent last few weeks trying to find the best way how to implement
>>dazukoFS (how to catch proper VFS events needed for on-access scanning).
>>One way is to use the FiST generator for transparent file systems. FiST
>>creates whole file system by duplicating VFS objects (super block, dentry,
>>inode, file) and linking them with objects in the lower layer (native file
>>system or other transparent file system). Because creating almost the
>>whole file system only to catch some VFS events is too much effort and
>>waste of time, I started to play directly with VFS object's operations.
> 
> This is interesting, but to me the greatest interest of the VFS approach
> using FiST was to benefit from the portability of FiST beyond just Linux.
> 
> How do you plan on supporting OS like Solaris or FreeBSD with this code ? It
> does sound like a duplication of effort, but I may be mistaken.
> 
> From a few of the paper that I read on the subject, I don't think that the
> processing overhead introduced by the extra work FiST does is really a
> problem.

Hi,

Aside from the fact that this is a Linux-only solution, I am concerned
that this implementation really is a deep "hack" into the Linux VFS. One
of the our goals for DazukoFS is that we gain respect from kernel
developers and perhaps be able to get into the default kernel. I think
that with this approach we will achieve neither.

I know we talked about trying to avoid VFS object duplication, but I
think that this alternative will not be acceptable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 6 Apr 2005 14:56
Picon

Re: dazukoFS - redirFS

Frantisek Hrbata wrote:
> You are absolutely right. The solution, as I introduced it, is for Linux
> kernels only, because it works directly with Linux VFS internals. It is
> intended to solve some Dazuko's problems on Linux kernels (for
> example ON-CLOSE events for Linux 2.6).
> I am not planning to port this to Solaris or FreeBSD. For these OS
> it will have to be completely rewritten.
> 
> Actually at this moment I am waiting for some feedback and then we will
> see if this is a right way.
> 
> I think, that processing overhead is not a problem, but the duplication of
> VFS objects could be. Please note, that for on-access scanning only some
> events like open, exec and close are needed. So, why to duplicate all VFS
> objects in the inode and dentry cache.
> 

Hi Franta,

If we were go ahead with VFS object duplication, and you were to make it for 
Linux 2.6 only, how small could it be? I have looked around at lots of 
examples (including the code generated from FiST) and it seems like there is 
an enormous amount to keep track of. It also seems like there are a lot of 
behavior and structural changes from each kernel version.

But if you were to take the current 2.6 Linux kernel and specialize a 
solution (based on VFS object duplication), how small and clean could you 
make it?

I know that you have done a lot of investigation on this, so I consider you
(Continue reading)

Permalink | Reply | 501 comments |
headers
Sami Tikka | 7 Apr 2005 14:01
Favicon

Re: 2.1.0-pre3 posted

John Ogness wrote:
> I don't understand your attitude. If you have better suggestions, I am
> open for them. The entire Trusted Application Framework was orginally
> developed because your company needed this feature! Don't complain, make
> a good suggestion! Until 2.1.0 is officially released, the new interface
> can still be changed. But please do not expect unsafe or
> platform-specific changes to the Dazuko interface.

My attitude comes from frustration: all suggestions I have made
regarding dazuko have been turned down by you. Perhaps we just see
things very differently. I know I was probably the first to request the
trusted application framework and obviously I am trying to guide the
development of TAF to a direction that would minimize re-work I have to do.

Here is my suggestion, with 2 points:

1) An application could ask to be trusted and the trust extended to its
child processes. The extension of trust to child processes would be
optional:

int dazukoRegisterTrusted(const char *groupName, const char *token, int
trust_children);

2) If the dazuko driver detects when a process has died and some other
unrelated process is running using the PID of a trusted process, I could
just ignore the handling of crashed scanner processes. I.e. a process
would remain trusted until the process itself asks not to be trusted
anymore or it has died.

I don't think this is unsafe and anyway it is up to the registered
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Ogness | 7 Apr 2005 15:42
Picon

Re: 2.1.0-pre3 posted

Sami Tikka wrote:
> My attitude comes from frustration: all suggestions I have made
> regarding dazuko have been turned down by you. Perhaps we just see
> things very differently. I know I was probably the first to request the
> trusted application framework and obviously I am trying to guide the
> development of TAF to a direction that would minimize re-work I have to do.

Yes, this is the main point where we are disagreeing. You are trying to 
minimize your work, whereas I am trying to make things as secure and 
flexible as possible (even if it means extra work for the developers).

> Here is my suggestion, with 2 points:
> 
> 1) An application could ask to be trusted and the trust extended to its
> child processes. The extension of trust to child processes would be
> optional:
> 
> int dazukoRegisterTrusted(const char *groupName, const char *token, int
> trust_children);

What is meant by child processes - threads, forks, both?

If a thread registers with trust_children=1, does Dazuko trust the parent also?

When a trusted process does a fork-exec, do I trust this new process as well?

I like the idea of providing an option to trust "related processes", but I 
am concerned about the overhead. It would mean that when an access event 
occurs, Dazuko must search through all trusted processes and check if 
somehow this process is "related" to one of them. This might be expensive.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frantisek Hrbata | 7 Apr 2005 17:29
Picon
Favicon

Re: dazukoFS - redirFS


On Wed, 6 Apr 2005, John Ogness wrote:

> Hi Franta,
>
> If we were go ahead with VFS object duplication, and you were to make it for
> Linux 2.6 only, how small could it be? I have looked around at lots of
> examples (including the code generated from FiST) and it seems like there is
> an enormous amount to keep track of. It also seems like there are a lot of
> behavior and structural changes from each kernel version.
>
> But if you were to take the current 2.6 Linux kernel and specialize a
> solution (based on VFS object duplication), how small and clean could you
> make it?

Annoying thing is, that we will have to take care of whole file system,
just to be able to catch some VFS events. Even if we will specialize our
transparent file system (dazukoFS) only for Linux kernels 2.6, there will
be still a lot of code, that we will have to maintain. Differences in the
VFS between kernels 2.2 to 2.6 are not  so big and I am afraid that
solution only for 2.6 kernels will not make the code smaller. With the
specialized file system for the 2.6 kernels we can only avoid some
portability problems. For these reasons I think we should use the FiST.
(even if it will require some maintenance from our side). Writing whole
file system from scratch is a lot of work and the code probably will not
be so much better than the code generated by FiST. Moreover with FiST it
will be portable to FreeBSD and Solaris.

> I know that you have done a lot of investigation on this, so I consider you
> to be the best qualified to answer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tikka, Sami | 7 Apr 2005 17:43
Favicon

RE: 2.1.0-pre3 posted

>-----Original Message-----
>From: John Ogness [mailto:jogness <at> antivir.de] 
>Sent: Thursday, April 07, 2005 4:43 PM
>To: Tikka, Sami
>Cc: dazuko-devel <at> nongnu.org
>Subject: Re: [Dazuko-devel] 2.1.0-pre3 posted
>
>> int dazukoRegisterTrusted(const char *groupName, const char *token, 
>> int trust_children);
>
>What is meant by child processes - threads, forks, both?
>
>If a thread registers with trust_children=1, does Dazuko trust 
>the parent also?

Yes, that was my meaning. dazukoRegisterTrusted would make the caller and
optionally its children trusted. Perhaps the parameter name should be changed
to "also_children" or something.

As for the question about threads and/or forks, I was under the impression
that on Linux they are the same thing as far as the kernel is concerned. What
I mean is that is it even possible to tell threads and processes apart in a
Linux kernel module?

I no longer remember how they work on FreeBSD and Solaris (It has been 6
years since I last coded something in FreeBSD kernel and 4 years since my
Solaris kernel days.)

I would be happy if also_children applied to forked processes. If it applies
to threads too, it would be a bonus. (I think if you trust one thread in the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane