Menu
▾
▴
devil-linux-discuss
|
From: Dick M. <di...@li...> - 2006-11-19 22:00:54
|
Hello, I've just updated from 1.2.9 to 1.2.11 and have encountered an odd problem. Maybe someone knows the cause: I have a /etc/postfix/local.d to keep my site config files. The mode of the directory is being set to 644 when I reboot even though it is correct when saving config. Curiously when I change the mode it also changes the mode of the same directory in the postfix jail - as if the two were linked. I suspect when the jail is created and this directory is copied the directory mode is being changed. Nothing to do with this upgrade but shouldn't there be a /var/run/saslauthd directory created in the postfix jail? How do I get it to create this? Dick |
|
From: Dick M. <di...@li...> - 2006-11-19 23:21:56
|
Dick Middleton wrote: > Hello, > > I've just updated from 1.2.9 to 1.2.11 and have encountered an odd > problem. Maybe someone knows the cause: > > I have a /etc/postfix/local.d to keep my site config files. The mode > of the directory is being set to 644 when I reboot even though it is > correct when saving config. Curiously when I change the mode it also > changes the mode of the same directory in the postfix jail I should clarify - the two are not linked at all - just an observational error. I'm not too sure what's happening except the mode is not staying how I set it. Dick |
|
From: Dick M. <di...@li...> - 2006-11-20 09:41:58
|
Dick Middleton wrote: > Hello, > > I've just updated from 1.2.9 to 1.2.11 and have encountered an odd problem. Some more things: The recently added aide is broken. It's obviously copied from Debian and some needed parts don't exist (such as /var/lib/aide, /etc/default, tempfile command and others). That's all very well except the script in /etc/cron.daily exists and fails. Firstly it fails because it doesn't have execute permission and secondly it fails because programs and directories it references don't exist. The recently added awstats is also broken for a similar reason. The script in cron.daily doesn't have execute permissions. I've not tried to run this but I notice various files with 1980 timestamps such as the aforementioned and /etc/awstats/awstats.model.conf. Whilst these are minor irritants it does bother me that things are being added to the system without proper auditing. This is supposed to be a secure system and addition of unverified software obviously gives an opportunity for malware to be unwittingly installed. Dick |
|
From: Bruce S. <bw...@ar...> - 2006-11-20 12:44:48
|
> Whilst these are minor irritants it does bother me that things are being added > to the system without proper auditing. This is supposed to be a secure system > and addition of unverified software obviously gives an opportunity for malware > to be unwittingly installed. Can you be more specific about what unverified software you're referring to? - BS |
|
From: Dick M. <di...@li...> - 2006-11-20 12:46:58
|
Bruce Smith wrote: >> Whilst these are minor irritants it does bother me that things are being added >> to the system without proper auditing. This is supposed to be a secure system >> and addition of unverified software obviously gives an opportunity for malware >> to be unwittingly installed. > > Can you be more specific about what unverified software you're referring to? aide and awstats. Dick |
|
From: Bruce S. <bw...@ar...> - 2006-11-20 13:02:21
|
> >> Whilst these are minor irritants it does bother me that things are being added > >> to the system without proper auditing. This is supposed to be a secure system > >> and addition of unverified software obviously gives an opportunity for malware > >> to be unwittingly installed. > > > > Can you be more specific about what unverified software you're referring to? > > aide and awstats. How do you suggest we audit them? Do you expect us to go through the source code line by line? (We'll get back to you in about 50 years, as soon as we're done with the kernel :) Or can we trust other sources to audit them? Some place that actually understands the source code perhaps? How about Novell/SuSE? Both of those packages are included with SuSE 10.1. Personally I didn't add them, and I've never used either of those packages. Hell, I didn't even know what those packages are until I searched my SuSE 10.1 DVD to see if they exist there. Do either of those packages start by _default_ when you boot DL? If so, then you _may_ be correct that there is a problem. Otherwise even malware won't hurt you if it never runs. You should know a little about the packages you designate to start at boot. What evidence do you have that either of those packages are malware? - BS |
|
From: Dick M. <di...@li...> - 2006-11-20 14:32:22
|
Bruce Smith wrote: >>>> Whilst these are minor irritants it does bother me that things are being added >>>> to the system without proper auditing. This is supposed to be a secure system >>>> and addition of unverified software obviously gives an opportunity for malware >>>> to be unwittingly installed. >>> Can you be more specific about what unverified software you're referring to? >> aide and awstats. > > How do you suggest we audit them? Do you expect us to go through the > source code line by line? These things are always difficult. I suppose just trying it out might be a good start. If you've worked with it and configured it to suit DL organisation then you'll know what it comprises. > (We'll get back to you in about 50 years, as > soon as we're done with the kernel :) :-) > Or can we trust other sources to audit them? That's up to you. We trust you, we have to and we want to. > Personally I didn't add them, and I've never used either of those > packages. Quite. The fact that aide doesn't work tells a story. > Do either of those packages start by _default_ when you boot DL? Yes. Any program/script placed in /etc/cron.daily for example will be executed as root. So far as I know this is the only way aide is executed. Had aide install been good then everybody would be running it whether they wanted to or not. There's a thing called logwatch also arrived in this DL version which does work. It is also started in cron.daily. First I knew about it was its report in my inbox. > If so, then you _may_ be correct that there is a problem. > What evidence do you have that either of those packages are malware? I hope there isn't any. Dick |
|
From: Dick M. <di...@li...> - 2006-11-20 21:51:55
|
Bruce Smith wrote: >>> Do either of those packages start by _default_ when you boot DL? >>> >> Yes. Any program/script placed in /etc/cron.daily for example will be executed >> as root. So far as I know this is the only way aide is executed. Had aide >> install been good then everybody would be running it whether they wanted to or >> not. There's a thing called logwatch also arrived in this DL version which does >> work. It is also started in cron.daily. First I knew about it was its report >> in my inbox. >> > > OK, maybe the line in the crontab should be commented out by default. > (I'll leave that decision to Heiko) > > OTOH, the last time I checked, crond itself doesn't start by default. > And if/when you turn on cron, you it's a good idea to edit/check the > crontabs. I think this is uncovering more than I intended but since we've started, in my opinion DL should not have scripts for packages installed in cron.daily etc. Instead I suggest it should place them in some other directory. It should then create symbolic links from cron.daily to the script at bootup if the package is enabled in sysconfig/config. Then it's similar to the way init.d works. That way DL retains some visibility and control of what is enabled and does not risk activating scripts unintentionally or unexpectedly. Dick |
|
From: Kari M. <kar...@tr...> - 2006-11-20 22:11:29
Attachments:
smime.p7s
|
Dick Middleton wrote:
> Bruce Smith wrote:
>>>> Do either of those packages start by _default_ when you boot DL?
>>>>
>>> Yes. Any program/script placed in /etc/cron.daily for example will be executed
>>> as root. So far as I know this is the only way aide is executed. Had aide
>>> install been good then everybody would be running it whether they wanted to or
>>> not. There's a thing called logwatch also arrived in this DL version which does
>>> work. It is also started in cron.daily. First I knew about it was its report
>>> in my inbox.
>>>
>> OK, maybe the line in the crontab should be commented out by default.
>> (I'll leave that decision to Heiko)
> >
>> OTOH, the last time I checked, crond itself doesn't start by default.
>> And if/when you turn on cron, you it's a good idea to edit/check the
>> crontabs.
>
> I think this is uncovering more than I intended but since we've started, in my
> opinion DL should not have scripts for packages installed in cron.daily etc.
> Instead I suggest it should place them in some other directory. It should then
> create symbolic links from cron.daily to the script at bootup if the package is
> enabled in sysconfig/config. Then it's similar to the way init.d works. That
> way DL retains some visibility and control of what is enabled and does not risk
> activating scripts unintentionally or unexpectedly.
I have to disagree on this, at least somewhat. First, it is customary
for people to make at least some changes to the scripts in cron.* dirs.
They have to remain writable. Second, creating automation to enable
certain links/scripts when a service is activated in
/etc/sysconfig/config, is, to my mind, wasting resources. You would,
for example have to specify wether to make the link into
cron.{hourly|daily|weekly|monthly|d}...
The Germans say, "Nein danke", and I say no thanks, too.
> Dick
-Kari ..not from Germany :-|
|
|
From: Bruce S. <bw...@ar...> - 2006-11-20 14:56:58
|
>> Do either of those packages start by _default_ when you boot DL? >> > > Yes. Any program/script placed in /etc/cron.daily for example will be executed > as root. So far as I know this is the only way aide is executed. Had aide > install been good then everybody would be running it whether they wanted to or > not. There's a thing called logwatch also arrived in this DL version which does > work. It is also started in cron.daily. First I knew about it was its report > in my inbox. > OK, maybe the line in the crontab should be commented out by default. (I'll leave that decision to Heiko) OTOH, the last time I checked, crond itself doesn't start by default. And if/when you turn on cron, you it's a good idea to edit/check the crontabs. - BS |
|
From: Dr. A. B. <be...@ec...> - 2006-11-20 13:59:28
|
> Dick Middleton wrote: > > The recently added aide is broken. It's obviously copied from > Debian and some needed parts don't exist (such as /var/lib/aide, > /etc/default, tempfile command and others). That's all very well > except the script in /etc/cron.daily exists and fails. Firstly it > fails because it doesn't have execute permission and secondly it > fails because programs and directories it references don't exist. > > The recently added awstats is also broken for a similar reason. > The script in cron.daily doesn't have execute permissions. I've not > tried to run this but I notice various files with 1980 timestamps > such as the aforementioned and /etc/awstats/awstats.model.conf. The time for test build/install/running/debug when the software is update is not enough. I added Aide and Awstats, in my personal distribution, about a year ago and the inclusion in devil-linux is May. Perhaps the Debian patch has modified something. Today I sent script update (and work) to Heiko for inclusion in CVS and next release. Now, Awstats (awstats.sourceforge.net) is a log analizer and you MUST edit configuration for YOUR system (my apache logs are in /chroot/var/lib/httpd and your?) and awstats.model.conf is a template config. Check http://econtools.economia.unife.it/devil-linux for other information. ALL file in /etc are 1980 timestamps > Whilst these are minor irritants it does bother me that things are > being added to the system without proper auditing. This is supposed > to be a secure system and addition of unverified software obviously > gives an opportunity for malware to be unwittingly installed. Untested maybe, unverified software ?!? for malware ?!? Argh..... maybe Ubuntu installation has security problems! Alberto +--------------------------+ | Dott. Alberto Benati | | System Administrator | | Faculty of Economics | | University of Ferrara | | be...@ec... | | Tel: +39 0532 45 5012 | +--------------------------+ |
