devil-linux-develop — developer discussions

Re: [Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:

> Heiko Zuerker wrote on 08.02.2004 20:43 MET:
> 
>> Bruce Smith wrote:
>>
>>>> I need to implement the option of remotely updating DL when it's on 
>>>> a USB stick or something.
>>>>
>>>> So far I couldn't really decide how I want to do this, so it's 
>>>> reliable and most of all secure.
>>>>
>>>> The update must be signed (pgp) and performed from within initrd, 
>>>> that's the easy part.
>>>>
>>>> My original idea was to add the iso image as boot.cd.new to the root 
>>>> of the media and then just check for it's existence, verify it, 
>>>> rename it to bootcd.iso and continue.
>>>
>>>
>>>
>>> So, the USB stick has to be large enough to hold TWO copies of the ISO?
>>
>>
>>
>> Yes correct.
>>
>>>> The major problem is that it's easy to temper with the verification 
>>>> of the signature, by replacing the initrd on the memory stick.
>>>
>>>
>>>
>>>
>>> You could put the sig on a secure location on the internet instead of on
>>> the media.  But then initrd would need the network up.  :-(
>>
>>
>>
>> That's then still the same problem, since initrd would need to verify 
>> itself,  which doesn't make much sense.
> 
> 
> Then checking a signature of the iso does not make any sense either
> if the initrd is tampered with. This seems to be a hen-and-egg problem.
> 

At least we could use it to check that the new ISO image is valid and 
there were no transfer errors.

Heiko

Re: [Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:

> Heiko Zuerker wrote on 08.02.2004 20:46 MET:
> 
>> Friedrich Lobenstock wrote:
>>
>>> Bruce Smith wrote on 08.02.2004 17:50 MET:
>>>
>>>>> The update must be signed (pgp) and performed from within initrd, 
>>>>> that's the easy part.
>>>>>
>>>>> My original idea was to add the iso image as boot.cd.new to the 
>>>>> root of the media and then just check for it's existence, verify 
>>>>> it, rename it to bootcd.iso and continue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So, the USB stick has to be large enough to hold TWO copies of the ISO?
>>>
>>>
>>>
>>>
>>> Hmmm...yes we can not overwrite the current ISO as it is currently
>>> mounted. What if we go back to load everything into memory? Then
>>> we could just replace the ISO on the memory stick (incl. its
>>> signature file) in place. What is cheaper? RAM or USB-Memory sticks?
>>
>>
>>
>> That would require hundreds of MBs. I would say if somebody wants to 
>> use this feature, he has to provide the necessary space on this stick 
>> or whereever it is on.
>>
>>> BTW how do we handle the ISOs created with custom-cd?
>>
>>
>>
>> Since the User will replace the ISO himself, he can do it with 
>> whatever version he prefers.
> 
> 
> I mean how do you check the signature if the user did run custom-cd?
> How do we support security against tempering that way?

Actually the user has to provide his own key pair. It's like the signing 
of the etc.tar.bz2, the user has to burn his own public key onto the ISO 
with custom-cd.

Heiko

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Friedrich Lobenstock wrote on 09.02.2004 01:47 MET:
> Bruce Smith wrote on 09.02.2004 01:28 MET:
> 
>> Sure, if that can be done.  I was worried about problems updating a
>> running system (replacing libraries in use, etc.), which is why I
>> suggested booting off CD.
> 
> 
> It has to be done in the initrd anyway and you are not changing those 
> libraries when doing the update. And yes this might be a problem of its 
> own, we can not change the initrd anymore. Hmmmmm.....then initrd needs 
> some fixed parts (does not change across stable version) which loads the 
> varibale ones, taking into account to update those if an "update CD" 
> exists. Then the rest of the system is updated. Now this might also be a 
> good idea to include the update script _from_ CD. This way we can 
> provide for a more complicated if we did not think about a specific 
> update problem later and as this script is tamper proof (on CD!) it can 
> check all the signatures against a provided signature file (is that 
> really needed?).
> 
> Sounds to get complicated. What do you think?

Maybe I'm just over-complicating things here...

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote on 09.02.2004 01:28 MET:
>>>What about automatically updating the stick from CD?  Burn the new image
>>>on CD, boot from CD, and it copies itself to the USB stick.  It could
>>>also be used to initially create a bootable stick (blank).
>>>
>>>Just a thought, CD drives are a LOT cheaper than big memory sticks.
>>
>>What if it boots of off the USB stick, checks for an "update-CD" (just a 
>>normal CD, but created from a newer ISO), does an update if necessary and 
>>then moves one?
> 
> 
> Sure, if that can be done.  I was worried about problems updating a
> running system (replacing libraries in use, etc.), which is why I
> suggested booting off CD.

It has to be done in the initrd anyway and you are not changing those 
libraries when doing the update. And yes this might be a problem of its 
own, we can not change the initrd anymore. Hmmmmm.....then initrd needs 
some fixed parts (does not change across stable version) which loads the 
varibale ones, taking into account to update those if an "update CD" 
exists. Then the rest of the system is updated. Now this might also be a 
good idea to include the update script _from_ CD. This way we can provide 
for a more complicated if we did not think about a specific update problem 
later and as this script is tamper proof (on CD!) it can check all the 
signatures against a provided signature file (is that really needed?).

Sounds to get complicated. What do you think?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Bruce S. <bw...@ar...>]

> > What about automatically updating the stick from CD?  Burn the new image
> > on CD, boot from CD, and it copies itself to the USB stick.  It could
> > also be used to initially create a bootable stick (blank).
> > 
> > Just a thought, CD drives are a LOT cheaper than big memory sticks.
> 
> What if it boots of off the USB stick, checks for an "update-CD" (just a 
> normal CD, but created from a newer ISO), does an update if necessary and 
> then moves one?

Sure, if that can be done.  I was worried about problems updating a
running system (replacing libraries in use, etc.), which is why I
suggested booting off CD.

 - BS

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote on 09.02.2004 01:00 MET:
>>>>My original idea was to add the iso image as boot.cd.new to the root of 
>>>>the media and then just check for it's existence, verify it, rename it 
>>>>to bootcd.iso and continue.
>>>
>>>So, the USB stick has to be large enough to hold TWO copies of the ISO?
>>
>>Yes correct.
> 
> 
> Is anyone ever going to use the feature?  1GB sticks are EXPENSIVE!!!
> 
> What about automatically updating the stick from CD?  Burn the new image
> on CD, boot from CD, and it copies itself to the USB stick.  It could
> also be used to initially create a bootable stick (blank).
> 
> Just a thought, CD drives are a LOT cheaper than big memory sticks.

What if it boots of off the USB stick, checks for an "update-CD" (just a 
normal CD, but created from a newer ISO), does an update if necessary and 
then moves one?

Eg. tell the on-site operator (secretary or whoever is able to help you) to 
burn the CD put it in the machine, reboot it and after it's back up again 
remove the CD. If you boot from CD it would possibly mount the ISO from 
there  and you can't remove the disc till the next reboot.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Postfix milters?

[Bruce S. <bw...@ar...>]

> ... but take a look at http://mailtools.anomy.net/

Has anyone tried anomy on DL?  Does DL come with all the perl modules
required?

 - BS

Re: [Devil-linux-develop] remote update

[Bruce S. <bw...@ar...>]

> >>My original idea was to add the iso image as boot.cd.new to the root of 
> >>the media and then just check for it's existence, verify it, rename it 
> >>to bootcd.iso and continue.
> > 
> > So, the USB stick has to be large enough to hold TWO copies of the ISO?
> 
> Yes correct.

Is anyone ever going to use the feature?  1GB sticks are EXPENSIVE!!!

What about automatically updating the stick from CD?  Burn the new image
on CD, boot from CD, and it copies itself to the USB stick.  It could
also be used to initially create a bootable stick (blank).

Just a thought, CD drives are a LOT cheaper than big memory sticks.

 - BS

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Heiko Zuerker wrote on 08.02.2004 20:50 MET:
> Friedrich Lobenstock wrote:
> 
>> Heiko Zuerker wrote on 08.02.2004 16:21 MET:
>>
>>> The major problem is that it's easy to temper with the verification 
>>> of the signature, by replacing the initrd on the memory stick.
>>
>> Then initrd needs to check its own signature first. If this does not
>> check out - hold the damned thing so the users _has to_ manually
>> intervene.
> 
> 
> That's the way I'm gonna do it, when we don't find a better solution.
> This means that we have to trust that the system is secure, which I 
> don't really like.
> The main problem is that when somebody gains access to the host, he can 
> replace the initrd, without any problems, with his own version...

Hmmmm.....what's this stuff M$ and the music industry wants in our
PCs?...

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Heiko Zuerker wrote on 08.02.2004 20:43 MET:
> Bruce Smith wrote:
> 
>>> I need to implement the option of remotely updating DL when it's on a 
>>> USB stick or something.
>>>
>>> So far I couldn't really decide how I want to do this, so it's 
>>> reliable and most of all secure.
>>>
>>> The update must be signed (pgp) and performed from within initrd, 
>>> that's the easy part.
>>>
>>> My original idea was to add the iso image as boot.cd.new to the root 
>>> of the media and then just check for it's existence, verify it, 
>>> rename it to bootcd.iso and continue.
>>
>>
>> So, the USB stick has to be large enough to hold TWO copies of the ISO?
> 
> 
> Yes correct.
> 
>>> The major problem is that it's easy to temper with the verification 
>>> of the signature, by replacing the initrd on the memory stick.
>>
>>
>>
>> You could put the sig on a secure location on the internet instead of on
>> the media.  But then initrd would need the network up.  :-(
> 
> 
> That's then still the same problem, since initrd would need to verify 
> itself,  which doesn't make much sense.

Then checking a signature of the iso does not make any sense either
if the initrd is tampered with. This seems to be a hen-and-egg problem.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Heiko Zuerker wrote on 08.02.2004 20:46 MET:
> Friedrich Lobenstock wrote:
> 
>> Bruce Smith wrote on 08.02.2004 17:50 MET:
>>
>>>> The update must be signed (pgp) and performed from within initrd, 
>>>> that's the easy part.
>>>>
>>>> My original idea was to add the iso image as boot.cd.new to the root 
>>>> of the media and then just check for it's existence, verify it, 
>>>> rename it to bootcd.iso and continue.
>>>
>>>
>>>
>>>
>>> So, the USB stick has to be large enough to hold TWO copies of the ISO?
>>
>>
>>
>> Hmmm...yes we can not overwrite the current ISO as it is currently
>> mounted. What if we go back to load everything into memory? Then
>> we could just replace the ISO on the memory stick (incl. its
>> signature file) in place. What is cheaper? RAM or USB-Memory sticks?
> 
> 
> That would require hundreds of MBs. I would say if somebody wants to use 
> this feature, he has to provide the necessary space on this stick or 
> whereever it is on.
> 
>> BTW how do we handle the ISOs created with custom-cd?
> 
> 
> Since the User will replace the ISO himself, he can do it with whatever 
> version he prefers.

I mean how do you check the signature if the user did run custom-cd?
How do we support security against tempering that way?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:

> Bruce Smith wrote on 08.02.2004 17:50 MET:
> 
>>> The update must be signed (pgp) and performed from within initrd, 
>>> that's the easy part.
>>>
>>> My original idea was to add the iso image as boot.cd.new to the root 
>>> of the media and then just check for it's existence, verify it, 
>>> rename it to bootcd.iso and continue.
>>
>>
>>
>> So, the USB stick has to be large enough to hold TWO copies of the ISO?
> 
> 
> Hmmm...yes we can not overwrite the current ISO as it is currently
> mounted. What if we go back to load everything into memory? Then
> we could just replace the ISO on the memory stick (incl. its
> signature file) in place. What is cheaper? RAM or USB-Memory sticks?

That would require hundreds of MBs. I would say if somebody wants to use 
this feature, he has to provide the necessary space on this stick or 
whereever it is on.

> BTW how do we handle the ISOs created with custom-cd?

Since the User will replace the ISO himself, he can do it with whatever 
version he prefers.

Heiko

Re: [Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:

> Heiko Zuerker wrote on 08.02.2004 16:21 MET:
> 
>> The major problem is that it's easy to temper with the verification of 
>> the signature, by replacing the initrd on the memory stick.
> 
> 
> Then initrd needs to check its own signature first. If this does not
> check out - hold the damned thing so the users _has to_ manually
> intervene.

That's the way I'm gonna do it, when we don't find a better solution.
This means that we have to trust that the system is secure, which I 
don't really like.
The main problem is that when somebody gains access to the host, he can 
replace the initrd, without any problems, with his own version...

Heiko

Re: [Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:

>>I need to implement the option of remotely updating DL when it's on a 
>>USB stick or something.
>>
>>So far I couldn't really decide how I want to do this, so it's reliable 
>>and most of all secure.
>>
>>The update must be signed (pgp) and performed from within initrd, that's 
>>the easy part.
>>
>>My original idea was to add the iso image as boot.cd.new to the root of 
>>the media and then just check for it's existence, verify it, rename it 
>>to bootcd.iso and continue.
> 
> So, the USB stick has to be large enough to hold TWO copies of the ISO?

Yes correct.

>>The major problem is that it's easy to temper with the verification of 
>>the signature, by replacing the initrd on the memory stick.
> 
> 
> You could put the sig on a secure location on the internet instead of on
> the media.  But then initrd would need the network up.  :-(

That's then still the same problem, since initrd would need to verify 
itself,  which doesn't make much sense.

Heiko

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote on 08.02.2004 17:50 MET:
>>The update must be signed (pgp) and performed from within initrd, that's 
>>the easy part.
>>
>>My original idea was to add the iso image as boot.cd.new to the root of 
>>the media and then just check for it's existence, verify it, rename it 
>>to bootcd.iso and continue.
> 
> 
> So, the USB stick has to be large enough to hold TWO copies of the ISO?

Hmmm...yes we can not overwrite the current ISO as it is currently
mounted. What if we go back to load everything into memory? Then
we could just replace the ISO on the memory stick (incl. its
signature file) in place. What is cheaper? RAM or USB-Memory sticks?

BTW how do we handle the ISOs created with custom-cd?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Friedrich L. <fl...@fl...>]

Heiko Zuerker wrote on 08.02.2004 16:21 MET:
> The major problem is that it's easy to temper with the verification of 
> the signature, by replacing the initrd on the memory stick.

Then initrd needs to check its own signature first. If this does not
check out - hold the damned thing so the users _has to_ manually
intervene.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] remote update

[Bruce S. <bw...@ar...>]

> I need to implement the option of remotely updating DL when it's on a 
> USB stick or something.
> 
> So far I couldn't really decide how I want to do this, so it's reliable 
> and most of all secure.
> 
> The update must be signed (pgp) and performed from within initrd, that's 
> the easy part.
> 
> My original idea was to add the iso image as boot.cd.new to the root of 
> the media and then just check for it's existence, verify it, rename it 
> to bootcd.iso and continue.

So, the USB stick has to be large enough to hold TWO copies of the ISO?

> The major problem is that it's easy to temper with the verification of 
> the signature, by replacing the initrd on the memory stick.

You could put the sig on a secure location on the internet instead of on
the media.  But then initrd would need the network up.  :-(

 - BS

[Devil-linux-develop] remote update

[Heiko Z. <he...@zu...>]

Hey folks,

I need to implement the option of remotely updating DL when it's on a 
USB stick or something.

So far I couldn't really decide how I want to do this, so it's reliable 
and most of all secure.

The update must be signed (pgp) and performed from within initrd, that's 
the easy part.

My original idea was to add the iso image as boot.cd.new to the root of 
the media and then just check for it's existence, verify it, rename it 
to bootcd.iso and continue.
The major problem is that it's easy to temper with the verification of 
the signature, by replacing the initrd on the memory stick.

any ideas? suggestions ?

cu
   Heiko

[Devil-linux-develop] [fmII] PHP 4.3.5RC2 released (Testing branch)

[<no...@fr...>]

This email is to inform you about the release of version '4.3.5RC2' of
'PHP' through freshmeat.net. All URLs and other useful information can be
found at

    http://freshmeat.net/projects/php/

The changes in this release are as follows:
This version contains several bugfixes, improvements, and crash-fixes.
 

Project description:
PHP is a widely-used Open Source general-purpose scripting language
that is especially suited for Web development and can be embedded
into HTML. Its syntax draws upon C, Java, and Perl, and is easy to
learn. PHP runs on many different platforms and can be used as a
standalone executable or as a module under a variety of Web servers.
It has excellent support for databases, XML, LDAP, IMAP, Java,
various Internet protocols, and general data manipulation, and is
extensible via its powerful API. It is actively developed and
supported by a talented and energetic international team. Numerous
Open Source and commercial PHP-based application packages are
available. 

Trove categories:
[Development Status  ] 6 - Mature
[Intended Audience   ] Developers
[License             ] The PHP License
[Programming Language] C, PHP
[Topic               ] Internet :: WWW/HTTP :: Dynamic Content, Software
Development :: Interpreters 

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net 

[Devil-linux-develop] [fmII] lm_sensors 2.8.4 released (Default branch)

[<no...@fr...>]

This email is to inform you about the release of version '2.8.4' of
'lm_sensors' through freshmeat.net. All URLs and other useful information
can be found at

    http://freshmeat.net/projects/lm_sensors/

The changes in this release are as follows:
This version features w831785ts support. It includes fixes to it87,
i2c-piix4, and the default sensors.conf configuration. There were
code clean ups to adm1025, adm1026, and libsensors. There is improved
support for i2c eeprom for 2.6.x kernels. There are other minor
tweaks and fixes. 

Project description:
lm_sensors provides essential drivers for monitoring the temperatures,
voltages, and fans of Linux systems containing devices such as the
LM78 and LM75. It contains drivers for sensor chips and I2C and SMBus
masters. It also contains text-based tools for sensor reporting, and
a library for sensors access called 'libsensors'. It also contains
tools for sensor hardware identification and I2C bus probing. 

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based)
[Intended Audience   ] End Users/Desktop
[License             ] OSI Approved :: GNU General Public License (GPL)
[Operating System    ] POSIX :: Linux
[Topic               ] System :: Hardware, System :: Monitoring 

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net 

Re: [Devil-linux-develop] anti-virus & rar?

[Heiko Z. <he...@zu...>]

Heiko Zuerker wrote:
> hzu...@ra... wrote:
> 
>> On 02/06/2004 03:45:42 PM Friedrich Lobenstock wrote:
>>
>>> Bruce Smith wrote on 06.02.2004 21:28 MET:
>>>
>>>> I've got postfix/clamav/spamassassin/sagator running on a test box and
>>>> I've been forwarding myself spam and viruses to test it out.
>>>>
>>>> I sent myself the test Eicar virus signature that comes with comes
>>>
>>>
>>> with
>>>
>>>> sagator, and it caught it.  I then sent the virus in a zip file,
>>>
>>>
>>> gziped,
>>>
>>>> bzip2'ed, and a zip file inside a zip file, and it caught them all.
>>>> Then I sent the virus inside the .rar file supplied by sagator, and it
>>>> did NOT catch it.  The program unrar is on my DL box and runs fine.
>>>>
>>>> # whereis unrar
>>>> unrar: /usr/bin/unrar
>>>>
>>>> What am I missing?  Or is something broken?
>>>
>>>
>>> Try copying the rar file to this system.
>>> What is the output of "file .....rar"? What if you run rar manually
>>> on this file?
>>
>>
>>
>> Is unrar in the sagator chroot ?
>> Does sagator expect it in a different path?
> 
> 
> I just saw in my log the following line:
> Feb  6 19:09:43 src@gate clamd[585]: RAR support disabled.

I enabled rar support in clamav.conf , but it still doesn't work.

I saw in the current CVS version of sagator are fixes for the 
decompressor module. But I think we should wait until the next release 
is available, since he did some changes to the config file, too.

Heiko

[Devil-linux-develop] [ devil-linux-Feature Requests-892182 ] add cfengine

[SourceForge.net <no...@so...>]

Feature Requests item #892182, was opened at 2004-02-06 19:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=892182&group_id=34096

Category: Packages
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: add cfengine

Initial Comment:
http://www.cfengine.org/
http://www.linuxjournal.com/article.php?sid=6848

Cfengine, or the configuration engine is an autonomous
agent and a middle to high level policy language for
building expert systems which administrate and
configure large computer networks. Cfengine uses the
idea of classes and a primitive intelligence to define
and automate the configuration and maintenance of
system state, for small to huge configurations.
Cfengine is designed to be a part of a computer immune
system, and can be thought of as a gaming agent. It is
ideal for cluster management and has been adopted for
use all over the world in small and huge organizations
alike.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=892182&group_id=34096

Re: [Devil-linux-develop] anti-virus & rar?

[Heiko Z. <he...@zu...>]

hzu...@ra... wrote:
> On 02/06/2004 03:45:42 PM Friedrich Lobenstock wrote:
> 
>>Bruce Smith wrote on 06.02.2004 21:28 MET:
>>
>>>I've got postfix/clamav/spamassassin/sagator running on a test box and
>>>I've been forwarding myself spam and viruses to test it out.
>>>
>>>I sent myself the test Eicar virus signature that comes with comes
>>
>>with
>>
>>>sagator, and it caught it.  I then sent the virus in a zip file,
>>
>>gziped,
>>
>>>bzip2'ed, and a zip file inside a zip file, and it caught them all.
>>>Then I sent the virus inside the .rar file supplied by sagator, and it
>>>did NOT catch it.  The program unrar is on my DL box and runs fine.
>>>
>>># whereis unrar
>>>unrar: /usr/bin/unrar
>>>
>>>What am I missing?  Or is something broken?
>>
>>Try copying the rar file to this system.
>>What is the output of "file .....rar"? What if you run rar manually
>>on this file?
> 
> 
> Is unrar in the sagator chroot ?
> Does sagator expect it in a different path?

I just saw in my log the following line:
Feb  6 19:09:43 src@gate clamd[585]: RAR support disabled.

Heiko

[Devil-linux-develop] DEVELOPERWORKS: COUNTERING BUFFER OVERFLOWS

[Heiko Z. <he...@zu...>]

DEVELOPERWORKS: COUNTERING BUFFER OVERFLOWS

"This article discusses the top vulnerability in Linux/UNIX
systems: buffer overflows. This article first explains what
buffer overflows are and why they're both so common and so
dangerous..."

COMPLETE STORY:
http://nl.internet.com/ct.html?rtr=on&s=1,pi0,1,1d2b,k0o3,1xhv,1a3h

Re: [Devil-linux-develop] anti-virus & rar?

[Friedrich L. <fl...@fl...>]

Bruce Smith wrote on 06.02.2004 21:54 MET:
>>
>>Try copying the rar file to this system.
> 
> 
> It is the exact file I copied from:
> .../lfssystem/data/build/tmp/sagator/test/pack/test.rar
> 
> These are files that sagator supplies for testing. 
> (along with other files containing virus sigs, which are all caught)
> 
> 
>>What is the output of "file .....rar"? What if you run rar manually
>>on this file?
> 
> 
> # from my DL test box:
> 
> root@test:/tmp # file test.rar
> test.rar: RAR archive data, v14, os: Unix
> 
> root@test:/tmp # unrar l test.rar
>  
> UNRAR 3.20 freeware      Copyright (c) 1993-2003 Eugene Roshal
>  
> Archive test.rar
>  
>  Name             Size   Packed Ratio  Date   Time     Attr      CRC   Meth Ver
> -------------------------------------------------------------------------------
>  d                   0        0   0% 02-07-03 13:03 drwxrwxr-x 00000000 m0  2.0
>  emptydir            0        0   0% 02-07-03 13:03 drwxrwxr-x 00000000 m0  2.0
>  useddir             0        0   0% 02-07-03 15:14 drwxrwxr-x 00000000 m0  2.0
>  file                9       21 100% 02-07-03 13:03 -rw-rw-r-- FFE2DDD2 m3b 2.9
>  empty               0        8   0% 02-07-03 13:03 -rw-rw-r-- 00000000 m3b 2.9
>  Eicar             178      172  96% 16-06-03 07:50 -rw-rw-r-- 38612FED m3b 2.9
> -------------------------------------------------------------------------------
>     6              187      201 100%
>  
> root@test:/tmp #


Hmmmm.....out o luck :-(

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________