RE: [PATCH] Set trusted pid feature to Dazuko

Sorry about not getting back sooner. I've been busy releasing a new version
of our Linux AV product. Now it is done and it is time to catch up with
mailing lists.

>-----Original Message-----
>From: John Ogness [mailto:[email protected]] 
>Sent: Monday, October 04, 2004 11:22 PM
>To: Tikka, Sami
>Cc: [email protected]
>Subject: Re: [PATCH] Set trusted pid feature to Dazuko
>
>
>Tikka, Sami wrote:
>> The problem is that Dazuko will intercept the open syscall from the 
>> scanner daemon. To prevent that, I have added a new feature 
>to Dazuko: 
>> the possibility to allow a process-id (and its children) without 
>> asking permission from a registered daemon.
>
>1. I don't like the idea of using "Pid" in the Dazuko 
>Interface. In some 
>systems a number may not effectively be able to describe another 
>process. I prefer to use something more abstract, which can be 
>specialized for the various platforms. (Something similar to dazuko_id 
>except in userspace.) However this would not be difficult to implement.

Fine, I'm sure we can come up with a suitable abstraction.

>2. My main concern is the implication of a registered process telling 
>Dazuko to trust (actually ignore) the actions of some other 
>non-registered process. What if that process ends or dies? Another 
>process (if based only on pid) could take it's place and be 
>free to work 
>unnoticed. Can Dazuko (and the other registered processes) 
>really trust 
>a registered process enough to know that it will keep tabs on the 
>"trusted process"?

Well, Dazuko needs to trust the registered process, right. 

The registered process could implement the bypass of access for the trusted
process and Dazuko would be happy about it. But what if the trusted process
dies? I say it is the job of the registered process to monitor the trusted
process.

Conceptually, from security point of view, it would be the same as having
Dazuko allow access for trusted processes, only it would be faster because a
couple of context switches are elimited. So it is a performance hack.

A registered process never needs to set the trusted pid in Dazuko, but if it
does, it should also assume the responsibility to monitor the trusted process
and reset or change the trusted pid in Dazuko should the trusted process die.

>I need to think about this. Right now your daemon could implement this 
>itself in userspace by immediately allowing access for "trusted" 
>processes. I am not sure I am ready to move this feature into 
>kernelspace.

Yes, this is exactly what I did in our alpha versions. Let me clarify the
flow of events:

Any process opens a file -> Dazuko sends OPEN event to registered process
(thread#1) -> Registered process sends a message to AV-scanner daemon, which
opens the file -> Dazuko sends OPEN event to registered process (thread#2)

At this point the registered process needs to identify that the OPEN was
caused by AV-scanner daemon and the access must be allowed.

Registered process (thread#2) returns access allowed to Dazuko -> AV-scanner
daemon scans the file, it is clean, result sent back to registered process
(thread#1) -> registered process (thread#1) returns access allowed to Dazuko.


It required the co-operation of 2 threads in the registered process to handle
the OPEN event.

But what if there are 2 simultaneous file accesses in the system? Thread#1
would start handling the first OPEN event, then thread#2 would start handling
the second OPEN event. Then thread#1 sends a message to AV-scanner daemon,
which opens the 1st file, which generates a 3rd OPEN event, but this time
there are no more threads in the registered process to handle the event. =>
The system deadlocks.

The only way to guarantee the system won't deadlock would be to somehow
determine the maximum number of simultaneous file accesses a system might
have (N) and have N+1 threads in the registered process. But I don't think it
is possible to find out a value for N.

Actually, there might be a way around this but does Dazuko allow it?

When dazukoGetAccess_TS() is called by a thread and it returns, is it
necessary that the corresponding dazukoReturnAccess_TS() be called from the
same thread? Or in other words: Is it possible for a thread to call
dazukoGetAccess_TS() and when it returns an event, call dazukoGetAccess_TS()
again without first calling dazukoReturnAccess_TS() for the first event?

If that's allowed, then the registered process only needs 2 threads: 1 thread
that receives events from Dazuko and 1 thread that returns access decisions
back to Dazuko.

The documentation of Dazuko does not really give an answer and the sample
code sort of least me to believe that a single thread must call
dazukoGetAccess_TS() and it must call dazukoReturnAccess_TS() before calling
dazukoGetAccess_TS() again. How is it?

-- Sami