secureaudit-general — General Questions and postings about SAL

[Secureaudit-general] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Secureaudit-general] Status of project?

[Patrick L. <pl...@ar...>]

I am looking for an auditing solution for the 2.6 series kernels, and 
noticed that the last release of secureaudit was for 2.4.18.  What is 
the current status of this project since the last release was nearly a 
year ago?  Are there plans to release 1.0 or continue on to a 2.6 
implementation?

Thanks,
Patrick Lang

[Secureaudit-general] RE: DITSCAP and LINUX

[Wolfe, W. M. <ww...@sp...>]

Lois,
 
  Linux-based systems have not been DITSCAP certified.  They can be
certified, but the process is lengthy and expensive.  Reason being is that
Linux has not passed a DoD security certification such as NIAP (Common
Criteria) yet.  It has passed DII COE certification (
http://diicoe.disa.mil/coe/kpc/linuxpc.html
<http://diicoe.disa.mil/coe/kpc/linuxpc.html> ), but this just means
compliance with the DII COE kernel.  There are a few efforts underway to
"fix" this.  See (http://news.com.com/2100-1001-984383.html
<http://news.com.com/2100-1001-984383.html> ) and
(http://www.linuxsecurity.com/articles/projects_article-6733.html
<http://www.linuxsecurity.com/articles/projects_article-6733.html> ).  Also
another group looking to certify Linux eventually (www.egovos.org
<http://www.egovos.org> ).  We're making our own efforts to enhance the
security of Linux to meet Common Criteria standards and are also looking for
a sponsor to fund an Open Source Technology Center we wish to stand up, it's
mission being to provide a U.S. Govt-wide resource for the research,
development, and supoprt of Linux and other open source software.  Hopefully
in the next year we'll see an open source operating system that meets all
the requirements for use in DoD.
 
Will
 
 
William M. Wolfe
SPAWARSYSCEN San DIego
Information Assurance Network Security Branch, 2872
ww...@sp... <mailto:ww...@sp...> 
(619) 553-4210 Phone
(619) 553-4245 Fax
 

----- Original Message ----- 
From: Kellett,  <mailto:Loi...@tm...> Lois, CIV, OASD(HA)/TMA 
To: 'god...@us...'
<mailto:'god...@us...'>  
Sent: Tuesday, April 08, 2003 7:58 AM
Subject: DITSCAP and LINUX


Mr. Godinez,

 

Is it correct that Linux-based systems have not and cannot be DITSCAP
certified?  If so, do you know of any "fix" in the works that would permit
Linux systems to meet the DITSCAP standards?

 

Lois

 

Lois Kellett
Military Health System

Interagency Program Integration & External Liaison
5111 Leesburg Pike; Suite 810
Falls Church, VA  22041
703-681-8794 or DSN 761-8794
fax:  703-681-8799
Email:  loi...@tm... <mailto:loi...@tm...> 
PTF:  703-696-9466 ext. 115

PTF email:  loi...@ws... <mailto:loi...@ws...> 

 

 

Re: [Secureaudit-general] More information on SAL...

[Axelle A. (LMC) <Axe...@er...>]

>
>
>In the US, generally, logs produced by computers are submitted as 
>hearsay evidence, this is not part of a requirement for C2. In talking 
>with several Legal forensics experts though, up to this point there have 
>been no major Challenges to the validity of the data.
>
Okay... collected as hearsay evidence... this makes sense.

>Again, from what we've heard from the "legal experts," log data is 
>typically Entered as evidence, but we're concerned about the situation 
>that might arise from someone challenging the data as valid, since the 
>case could be made that most log data can easily be modified. We want to 
>provide a way to produce audit logs that are forensically sound, similar 
>to the way physical evidence is collected.
>
Ok.

>>==> more exactly, do you mean somebody has to prove computer data has
>>not been modified (-- meaning it is unfeasible without detection), or
>>do you mean for data not be retained as evidence one should prove it
>>has been modified ? can you provide more references about those facts?
>>    
>>
>Besides providing C2 type of data, what we're shooting for is similar to
>what physical forensics examiners have to do, maintain a chain of 
>custody. We're developing a way to "maintain a chain of custody" of 
>audit data from the kernel to storage on disk. We want the data 
>protected and the process shown to be forensically sound, so that data 
>recorded will stand up to any challenge in a court.
>
Well, you're not really answering my question, but from your previous 
answers I have the feeling that you're rather in the second option where 
for data not to be retained as "valid" evidence, someone would have to 
challenge successfully the log data and prove it has been modified.
Right ?

>
>  
>
>>**************
>>- about the "little files" that are kept on the client before being
>>sent to the logging server: ===> are they digitally signed ? wouldn't
>>it be possible for an intruder to corrupt those files before they get
>>sent to the logging server ?
>>    
>>
>
>There were lots of trade-offs with the little files.  Currently they are 
>not signed (performance issues) however we expect to be implementing a 
>process that will sign "little files" prior to being sent to the server. 
> The signature will be used to verify their integrity while on the 
>client. The signature should not be required on the data during 
>transmission or once stored so we do not see a requirement to actually 
>send the signatures.
>
Well, if there isn't any signature, the little files can be corrupted, 
and hence data logged may not be the real log data...
However, I do understand the performance trade-off + that this is under 
progress.

>>==> there seem to have been some benchmark tests. Would it possible to
>>publish those results ? What's the overhead induced by SAL ? how were
>>the benchmarks performed ?
>>    
>>
>
>We have no benchmark tests to release at this time...
>
That'd be very interesting... (suggest use of LMBench for instance).

Thanks very much for your answers. SAL seems to be a very interesting 
project, I'll keep an eye on it.
Regards
Axelle.

Re: [Secureaudit-general] More information on SAL...

[Javier G. <god...@sp...>]

Axelle

Here is our answer to your detailed questions...

>- Regarding legal evidence:
> The document says that logs produced by computers are not admissible
> as evidence unless it can be shown that they have not been modified.

Here we were citing section 69 of the Police and Criminal Evidence Act. 
A British law stating the admissibility of computer generated information.

> ==> is this a requirement specific to the U.S, or a general
> requirement from C2 specs ? (I think it's the first).

In the US, generally, logs produced by computers are submitted as 
hearsay evidence, this is not part of a requirement for C2. In talking 
with several Legal forensics experts though, up to this point there have 
been no major Challenges to the validity of the data.

> ==> to my understanding, this is not exactly true. I had the feeling
> that the court retained evidence with different levels of trust
> regarding the evidence. For instance a signed text would have more
> impact than unsigned text, but all texts were admissible in front of
> the court. I am unsure of this. Any feedback ? And as a matter of
> fact, I had also heard of cases where computer data had been retained
> as legal evidence, though that data did not have any digital signature
> for instance. Have you heard this too ? Have laws changed since ?

Again, from what we've heard from the "legal experts," log data is 
typically Entered as evidence, but we're concerned about the situation 
that might arise from someone challenging the data as valid, since the 
case could be made that most log data can easily be modified. We want to 
provide a way to produce audit logs that are forensically sound, similar 
to the way physical evidence is collected.

> ==> more exactly, do you mean somebody has to prove computer data has
> not been modified (-- meaning it is unfeasible without detection), or
> do you mean for data not be retained as evidence one should prove it
> has been modified ? can you provide more references about those facts?

Besides providing C2 type of data, what we're shooting for is similar to
what physical forensics examiners have to do, maintain a chain of 
custody. We're developing a way to "maintain a chain of custody" of 
audit data from the kernel to storage on disk. We want the data 
protected and the process shown to be forensically sound, so that data 
recorded will stand up to any challenge in a court.

> **************
> - about the "little files" that are kept on the client before being
> sent to the logging server: ===> are they digitally signed ? wouldn't
> it be possible for an intruder to corrupt those files before they get
> sent to the logging server ?

There were lots of trade-offs with the little files.  Currently they are 
not signed (performance issues) however we expect to be implementing a 
process that will sign "little files" prior to being sent to the server. 
 The signature will be used to verify their integrity while on the 
client. The signature should not be required on the data during 
transmission or once stored so we do not see a requirement to actually 
send the signatures.

> **************
> - performance issues:
> ==> I want to make sure. If the audit daemon is stopped (auditd) on
> the client, then actually, the system calls continue to be audited and
> to fill the kernel buffer space allocated for this. If the daemon is
> stopped too long, then audited data may be lost. On the other hand, if
> the audit daemon is restarted before the buffer is filled, then
> actually nothing is lost. Right ?

That's the way it's designed however we do not believe that is currently 
the way it's implemented.  At least from the default scripts point of 
view. Currently the kernel buffers data for a period of time.  When 
auditd runs it sits in a loop and empties the kernel's buffer space.  It 
then stores the data to disk.  If auditd is killed the buffer space will 
fill up again. When auditd is restarted, we believe that is clears the 
buffer space and begins the process again.  We are looking at a number 
of security issues on the client with boundary conditions.


> ==> there seem to have been some benchmark tests. Would it possible to
> publish those results ? What's the overhead induced by SAL ? how were
> the benchmarks performed ?

We have no benchmark tests to release at this time...

The SAL Team

Re: [Secureaudit-general] auditclient fails to launch: PEM/SSL error.

[Javier G. <god...@sp...>]

Axelle

What distro and what version of openssl are you using..?
Your CA files look fine.

Javier


On Monday 17 March 2003 01:31 pm, Axelle Apvrille (LMC) wrote:
> Hi,
>
> I'm trying SAL on a two-machine configuration (a client + a server).
> - sald is launched on the server
> - auditd is launched on the client: ./auditd -b saltmp -d /tmp
> It seems to be working as I already have some data in a file called
> /tmp/saltmp.0
>
> but auditclient won't work:
> [root@munster client]# ./auditclient -a X.Y.Z.W -b saltmp -c
> /home/lmcaxpr/sal/CA/ -d /tmp -v &
> [1] 1808
> [root@munster client]# network.c:160 Error loading private key from file
> 0:error:06065064:digital envelope routines:EVP_DecryptFinal:bad
> decrypt:evp_enc.c:277:
> 0:error:0906A065:PEM routines:PEM_do_header:bad decrypt:pem_lib.c:451:
> 0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:missing asn1
> eos:ssl_rsa.c:707:
>
>
> On the client, in /home/lmcaxpr/sal/CA I have:
>
> -rw-r--r--    1 lmcaxpr  lmcaxpr      1273 Mar 17 16:12 X.Y.Z.Wcert.pem
> -rw-r--r--    1 lmcaxpr  lmcaxpr      1751 Mar 17 16:12 X.Y.Z.Wkey.pem
> -rw-r--r--    1 lmcaxpr  lmcaxpr      4334 Mar 17 16:12 X.Y.Z.W.pem
> -rw-r--r--    1 lmcaxpr  lmcaxpr      1029 Mar 17 16:12 X.Y.Z.Wreq.pem
> -rw-r--r--    1 lmcaxpr  lmcaxpr      3061 Mar 17 16:12 root.pem
>
> where X.Y.Z.W is the client's IP address.
>
> Any suggestion ? Haven't I copied the right files in CA ?
>
> Regards,
> Axelle.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Secureaudit-general mailing list
> Sec...@li...
> https://lists.sourceforge.net/lists/listinfo/secureaudit-general

[Secureaudit-general] auditclient fails to launch: PEM/SSL error.

[Axelle A. (LMC) <Axe...@er...>]

Hi,

I'm trying SAL on a two-machine configuration (a client + a server).
- sald is launched on the server
- auditd is launched on the client: ./auditd -b saltmp -d /tmp
It seems to be working as I already have some data in a file called 
/tmp/saltmp.0

but auditclient won't work:
[root@munster client]# ./auditclient -a X.Y.Z.W -b saltmp -c 
/home/lmcaxpr/sal/CA/ -d /tmp -v &
[1] 1808
[root@munster client]# network.c:160 Error loading private key from file
0:error:06065064:digital envelope routines:EVP_DecryptFinal:bad 
decrypt:evp_enc.c:277:
0:error:0906A065:PEM routines:PEM_do_header:bad decrypt:pem_lib.c:451:
0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:missing asn1 
eos:ssl_rsa.c:707:


On the client, in /home/lmcaxpr/sal/CA I have:

-rw-r--r--    1 lmcaxpr  lmcaxpr      1273 Mar 17 16:12 X.Y.Z.Wcert.pem
-rw-r--r--    1 lmcaxpr  lmcaxpr      1751 Mar 17 16:12 X.Y.Z.Wkey.pem
-rw-r--r--    1 lmcaxpr  lmcaxpr      4334 Mar 17 16:12 X.Y.Z.W.pem
-rw-r--r--    1 lmcaxpr  lmcaxpr      1029 Mar 17 16:12 X.Y.Z.Wreq.pem
-rw-r--r--    1 lmcaxpr  lmcaxpr      3061 Mar 17 16:12 root.pem

where X.Y.Z.W is the client's IP address.

Any suggestion ? Haven't I copied the right files in CA ?

Regards,
Axelle.

[Secureaudit-general] More information on SAL...

[Axelle A. (LMC) <Axe...@er...>]

Hi all,
I'm new to this SAL project, and have just been basically through the 
SAL documentation ("SAL Software Design Document 1.0"). There seems to 
be a bunch of interesting ideas, the best auditing system I've been 
looking at so far...
However, I have a few questions I hope somebody might care to answer.

*************
- Regarding legal evidence:
The document says that logs produced by computers are not admissible as 
evidence unless it can be shown that they have not been modified.

==> is this a requirement specific to the U.S, or a general requirement 
from C2 specs ? (I think it's the first).

==> to my understanding, this is not exactly true. I had the feeling 
that the court retained evidence with different levels of trust 
regarding the evidence. For instance a signed text would have more 
impact than unsigned text, but all texts were admissible in front of the 
court. I am unsure of this. Any feedback ?
And as a matter of fact, I had also heard of cases where computer data 
had been retained as legal evidence, though that data did not have any 
digital signature for instance. Have you heard this too ? Have laws 
changed since ?

==> more exactly, do you mean somebody has to prove computer data has 
not been modified (-- meaning it is unfeasible without detection), or do 
you mean for data not be retained as evidence one should prove it has 
been modified ? can you provide more references about those facts ?

**************
- about the "little files" that are kept on the client before being sent 
to the logging server:
===> are they digitally signed ? wouldn't it be possible for an intruder 
to corrupt those files before they get sent to the logging server ?

**************
- performance issues:
==> I want to make sure. If the audit daemon is stopped (auditd) on the 
client, then actually, the system calls continue to be audited and to 
fill the kernel buffer space allocated for this. If the daemon is 
stopped too long, then audited data may be lost. On the other hand, if 
the audit daemon is restarted
before the buffer is filled, then actually nothing is lost. Right ?

==> there seem to have been some benchmark tests. Would it possible to 
publish those results ? What's the overhead induced by SAL ? how were 
the benchmarks performed ?

Regards,
Axelle.