headers
John Ogness | 1 Feb 2005 20:45
Picon

2.0.5 released

Hi,

Dazuko 2.0.5 has finally been released. The big changes from 2.0.4 are 
mostly the support for Linux 2.6. An enormous amount of work was done to 
detect and support the many variations of the LSM API in distributions. 
There were also improvements on file access detection under Linux 2.2/2.4.

2.0.5 is the last release in the 2.0.x series. I am now devoting all my 
time to the 2.1.0 release. Upcoming features include:
   - greatly improved on_close support (faster AND better)
   - eliminating all memory-leak/slowdown problems using on_close
   - separate access_mask/include/exclude settings for groups
   - extended Dazuko interface for caching support
   - a new "trusted application" framework
   - a cross-platform (XP) layer on the userspace side
   - ruby and lua implementations of the Dazuko interface

I was originally hoping to get DazukoFS included for the 2.1.0 version, 
but this is no longer realistic. DazukoFS is now planned for 2.2.0. 
However, pre-releases of 2.2.0 will start showing up very soon because 
this is a major change in how Dazuko works and I think it will take 
quite a while to get it working right. The new architectural changes in 
Dazuko that will be present in 2.1.0 are moving towards a DazukoFS 
mentality. This means that the 2.1.x series will not only introduce many 
useful and important features, but is also making a transition to a 
VFS-based access-detection architecture.

On a side note, I had an accident last Friday while riding my bicycle to 
work. I seemed to have torn something in my right shoulder, which has 
made using a computer quite difficult. This has already caused some
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 5 Feb 2005 17:08
Picon

2.1.0-birthday (pre2) posted

Hi,

Seeing as how it is Dazuko's 3rd birthday, I have posted a pre-release 
of 2.1.0. This represents not only a merge of 2.0.5 and the new features 
from 2.1.0-pre1, but it also includes many additional new features 
planned for 2.1.0, such as:
   - no more open lists (ON_CLOSE 100% reliable, no memory leaks)
   - separate configuration settings for groups
   - interface ported to Ruby, Lua, and PHP

Another cool feature (which was greatly improved from the 2.1.0-pre1 
version) is DummyOS. This is a sample extension of Dazuko to help people 
interested in porting Dazuko to other systems. It runs completely in 
userspace and uses the real DazukoXP and DazukoIOXP core for processing. 
This means that it can also be used for testing/development of the XP 
(cross-platform) core.

Getting it up and running is easy:
$ ./configure --system=dummmyos
$ make
$ ./dazuko.bin

Then you can open a second terminal and build/run the example program:
$ cd example_c
$ make
$ ./example /tmp

When you go back to the first terminal, you can enter fake file access 
events. (Use "help" for a list of available commands.) For example:
DummmyOS kernel> open /tmp/file.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 9 Feb 2005 23:28
Picon

Re: mount/umount events?

Tikka, Sami wrote:
> I have a problem. I have recently realized that in order to maintain a
> consistent user-space scan result cache, the cache needs to be aware of
> changes in the filesystems i.e. mount and umount events.
> 
> Without mount/umount events the following would be possible:
> 
> 1. Mount a filesystem on a removable media (a cdrom, usb-stick, ...)
> 
> 2. Access a file on it. Scan result is cached. The (device, inode) pair is
> used to identify the file.
> 
> 3. Umount the filesystem
> 
> 4. Replace the removable media with another of the same kind
> 
> 5. Mount the new filesystem (presumably containing viruses). The new
> filesystem will have the same device number as the one previously mounted
> 
> 6. Access a file (with a virus) with the same inode number as the file in
> step 2 had. The scan result will be found in the cache => BOOM, you're
> infected

Hi,

It would seem to me that if you are caching the results of scanning file 
content, that you should use more than device/inode pairs for 
determining if the cache should be invalidated. Dazuko doesn't detect 
when files are modified, only when they are open/closed (and for Linux 
2.6 only opened). I fail to see how knowing about mount/umount makes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Calin A. Culianu | 15 Feb 2005 18:15

Dazuko on linux 2.4 and 2.6


I am sorry if this email is redundant or indicates my not having 
researched answers to my question, but I wanted to know what events dazuko 
can generate on linux 2.4 and on 2.6.  From reading the mailing list it 
sounds like only OPEN events are generated.  Read, write, and close events 
aren't.. is that the case?  Or am I misunderstanding what I've read?

Thanks,

-Calin
Permalink | Reply | 1 comment |
headers
John Ogness | 15 Feb 2005 19:05
Picon

Re: Dazuko on linux 2.4 and 2.6

Calin A. Culianu wrote:
> I am sorry if this email is redundant or indicates my not having 
> researched answers to my question, but I wanted to know what events 
> dazuko can generate on linux 2.4 and on 2.6.  From reading the mailing 
> list it sounds like only OPEN events are generated.  Read, write, and 
> close events aren't.. is that the case?  Or am I misunderstanding what 
> I've read?

Dazuko supports the following events (if configured for them):

open, close, exec, unlink, rmdir, close_modified

All of these events will work on all systems except Linux 2.6. With Linux 
2.6 only "open" and "exec" are supported. In the future (sometime this 
year), all events will also be supported for Linux 2.6.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
Tikka, Sami | 16 Feb 2005 15:28
Favicon

RE: mount/umount events?

>-----Original Message-----
>From: John Ogness [mailto:jogness <at> antivir.de] 
>Sent: Thursday, February 10, 2005 12:28 AM
>To: Tikka, Sami
>Cc: dazuko-devel <at> nongnu.org
>Subject: Re: mount/umount events?
>
>
>It would seem to me that if you are caching the results of 
>scanning file 
>content, that you should use more than device/inode pairs for 
>determining if the cache should be invalidated. Dazuko doesn't detect 
>when files are modified, only when they are open/closed (and for Linux 
>2.6 only opened). I fail to see how knowing about mount/umount makes 
>your solution safer. You have the same problem even if 
>mounting doesn't 
>take place.

Dazuko can detect if a file is opened for writing. I can remove a cache entry
whenever a file is opened for writing or the file is removed. That takes care
of most of the usual cases of file access. Then there's umount, which
invalidates a whole bunch of scan results at once. And then you came up with
this scenario:

>1. An evil program opens a file (but doesn't do anything with 
>it.. yet).
>
>2. User accesses a file. Scan result is cached. The (device, 
>inode) pair 
>is used to identify the file.
(Continue reading)

Permalink | Reply | 501 comments |
headers
John Ogness | 16 Feb 2005 16:36
Picon

Re: RE: mount/umount events?

Tikka, Sami wrote:
> Is there anything in dazuko that guarantees that the file cannot be changed
> between the time a scan daemon finds the file clean and the time the file is
> actually read or executed? I guess not. I agree that the window of
> vulnerability is very small but it still exists.

With the current implementation of Dazuko, the window will always exist. 
There are currently alternatives that are able to close this window, but 
only under certain circumstances:

http://www.filesystems.org/docs/avfs-security04/avfs.pdf

> So, in my opinion we have a problem if we have evil programs writing to files
> and keeping them open and nice programs reading them at the same time.

Yes, you are right. This is why Dazuko needs to move into the VFS layer. 
Hooking all the system calls isn't going to fix it. This is why I want to 
stop doing things wrong and start spending my energy to do things right.

Once Dazuko is in the VFS layer, we can add all kinds of events/mechanisms 
so that the window is 100% closed. This is my goal. This is a *REQUIREMENT* 
if Dazuko is to become a security solution.

> I agree it does not 100% solve my problem but like I said above, I do not
> think it is possible to solve it *totally*. I would be happy get it almost
> there, like 90% or 95%. Of course, I am happy if you can prove me wrong. I'd
> like nothing better than to have a 100% correct solution.

We can solve it, but not with system call hooks (or LSM).
(Continue reading)

Permalink | Reply | 501 comments |
headers
John Ogness | 22 Feb 2005 09:22
Picon

Re: Dazuko application

Benjamin Adler wrote:
> I just finished creating a small homepage for my first c++/qt/kde tool,
> which uses dazuko for file change notification. The homepage is
> http://politbuero.dyndns.org/~ben/imageserver, or
> http://www.kde-apps.org/content/show.php?content=20829 for the kde-apps
> entry. If you'd like, you can add it to the dazuko-applications-page.

I have included it on the Dazuko Applications page.

> The app is released under gpl, links against dazuko and even has some
> dazuko-files in its .tar.gz. Thats ok, right?

You should also include the LICENSE.bsd file in the "libdazuko" directory. 
This way people can see what license it is under.

I would also recommend including source files instead of compiled .o and .a 
files. Those object files may not work if someone has different system 
libraries than you.

> Do you already know if/when dazuko will properly report ON_CLOSE_MODIFIED
> events on linux 2.6? I'm supposed to install imageserver at a customer in
> mid-march, and I'm currently using an ugly and unreliable hack to make up
> for the lack of the ON_CLOSE_MODIFIED event.

Dazuko's support for Linux 2.6 won't include CLOSE events until the 2.2.x 
series. Hopefully we will have a pre-release of 2.2.0 sometime before June.

John Ogness

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 2 Mar 2005 22:03
Picon

2.0.6-pre1 posted

Hi,

With the release of Linux 2.6.11 comes another change in the LSM API. In 
order to properly support stacking, Dazuko needs to implement the entire 
LSM API. For this reason a new pre-release (2.0.6-pre1) has been posted.

I am no longer actively working on the 2.0.x series, so this is just a 
minor change to support Linux 2.6.11. Unless someone reports a problem, 
this will most likely become the official 2.0.6 version.

On a side note, I am just about ready to post a new pre-release of 
2.1.0, which will have full support for trusted applications. This will 
allow processes to register with Dazuko but not be required to perform 
file access control. This is particulary useful for anti-virus software, 
where the scanning process may not the same process as the file access 
control process.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 2 comments |

Gmane