Apparently sectool was not imported with mageia was forked...

sectool package is available in updates_testing
please test

CC: (none) => ennael1

Hi,


Soem changes :-)  but I think that something is wrong/not complete

1. I activated the mirror "Core updates testing", selected sectool-gui and installed the packages here under :
- sectool-gui-0.9.3-1.mga1                      mer 17 aoû 2011 17:46:08 CEST
- sectool-0.9.3-1.mga1                          mer 17 aoû 2011 17:46:06 CEST
- python-selinux-2.0.78-3.mga1                  mer 17 aoû 2011 17:46:05 CEST
- gettext-0.18.1.1-2.mga1                       mer 17 aoû 2011 17:46:02 CEST
- libgettextmisc-0.18.1.1-2.mga1                mer 17 aoû 2011 17:46:01 CEST
- libunistring0-0.9.3-4.mga1                    mer 17 aoû 2011 17:46:00 CEST
- libselinux1-2.0.78-3.mga1                     mer 17 aoû 2011 17:45:58 CEST

2. Konsole

3. Su -

4. run-parts /etc/cron.weekly/

5. Result on screen
[root@localhost ~]# run-parts /etc/cron.weekly/
/usr/share/sectool/scheduler/scheduler.py: inconsistent use of tabs and spaces in indentation
Traceback (most recent call last):
  File "/usr/sbin/sectool", line 22, in <module>
    from scheduler import scheduler, errors
  File "/usr/share/sectool/scheduler/scheduler.py", line 21, in <module>
    import rpm
ImportError: No module named rpm
[root@localhost ~]# 

Rmk :
I see a process awk in ksysguard at the begining (i suppose for the script makewhatis)

What happens if you install python-rpm?

CC: (none) => sander.lepik

Hi,

1. I installed python-rpm-4.8.1-10.mga1

2. Konsole with root

3. run-parts /etc/cron.weekly/

Result :
Seems ok and 'lots of' errors/warnings generated but this is another thing

... so now question is :
Is it normal that python-rpm is not required for sectool ?


Rmk :
Sectool-gui is not ok (/usr/share/sectool/sectool-gui.py: inconsistent use of tabs and spaces in indentation. Fatal Python error: could not import gnomevfs), I will see and open a new specific ticket for this

(In reply to comment #5)
> Rmk :
> Sectool-gui is not ok (/usr/share/sectool/sectool-gui.py: inconsistent use of
> tabs and spaces in indentation. Fatal Python error: could not import gnomevfs),
> I will see and open a new specific ticket for this

You probably need gnome-python-gnomevfs for this.

Those deps need testing and if required then sectool must be rebuilt with new requires.

Assignee: bugsquad => ennael1

Hi,

I installed 'gnome-python-gnomevfs-2.28.1-2.mga1' and now 'sectool-gui' start correctly

So to resume msec for 'run-parts /etc/cron.weekly/' need 
1. sectool (here under list of all packages selected automaticaly)
- sectool-gui-0.9.3-1.mga1
- sectool-0.9.3-1.mga1
- python-selinux-2.0.78-3.mga1
- gettext-0.18.1.1-2.mga1
- libgettextmisc-0.18.1.1-2.mga1
- libunistring0-0.9.3-4.mga1
- libselinux1-2.0.78-3.mga1

2. + python-rpm-4.8.1-10.mga1

3. and 'sectool-gui' need 'gnome-python-gnomevfs-2.28.1-2.mga1'

A+
Raph

(In reply to comment #6)
 
> Those deps need testing and if required then sectool must be rebuilt with new
> requires.

Just tested, without python-rpm sectool does not start and errors out.
Without gnome-python-gnomevfs sectool-gui does not start.

Fix already committed, waiting for review through my mentor and submission for a new updates_testing candidate.

Keywords: PATCH => (none)
Status: NEW => ASSIGNED
CC: (none) => doktor5000
Assignee: ennael1 => doktor5000

sectool-0.9.3-1.1.mga1.x86_64.rpm update_candidate (and sectool-gui) should be available in updates_testing already, which needs to be validated. Please also pay attention to added requires b/c of linking (gnome-python-gnomevfs and python-rpm).

But the other part of the problem is to fix msec itself, adding a require on sectools. Will do that tomorrow, unfortunately i don't have an answer on https://bugs.mageia.org/show_bug.cgi?id=1530 which also should go into msec update :(

msec-0.80.10-2.1.mga1 update candidate should be available in updates_testing, and also needs to be validated. Additionaly contains a fix for Bug 1530.

This appears to be affected by bug 2317.

This could be the mirrors not in sync, will need to be checked but I get an error whenever I open Mageia Update saying msec cannot be selected.

This does not depend on 2317.

msec update candidate should be available from mirrors which sync more often, f.ex. distrib-coffee, or ftp.mandrivauser.de. Maybe qa_updates wiki page should be updated so that mirror is used, that is reliable and syncs often.

If the error persists i'd need the output why it can't be selected. Will investigate in the meantime.

Depends on: 2317 => (none)

msec is there but not able to be selected - it gives the error whenever I open mageia.update - I think it must be missing sectool.

I tried with linuxcabal which did list sectool tho as well and it still gave the error. I'll leave it for now and try again tomorrow as its being a bit weird.

Just checked, and it worked without problem here. When selecting msec, it tells me it needs to install sectool additionaly. This is with ftp.mandrivauser.de as mirror.

As for linuxcabal mirror, yes both sectool and msec are available there, seems weird.

i586:

- gettext-0.18.1.1-2.mga1.i586 (SRPM gettext-0.18.1.1-2.mga1.src.rpm)
- libgettextmisc-0.18.1.1-2.mga1.i586 (SRPM gettext-0.18.1.1-2.mga1.src.rpm)
- libselinux1-2.0.78-3.mga1.i586 (SRPM libselinux-2.0.78-3.mga1.src.rpm)
- libunistring0-0.9.3-4.mga1.i586 (SRPM libunistring-0.9.3-4.mga1.src.rpm)
- python-rpm-4.8.1-10.mga1.i586 (SRPM rpm-4.8.1-10.mga1.src.rpm)
- python-selinux-2.0.78-3.mga1.i586 (SRPM libselinux-2.0.78-3.mga1.src.rpm)

Also as mentioned earlier - 

- gnome-python-gnomevfs (SRPM gnome-python-2.28.1-2.mga1.src.rpm)

Required from core/release so this is affected by bug 2317. These will need linking to updates when the update is pushed. Adding bug 2317 as a depends to help QA keep track of the linking being done. 

I'll check for any others.

SRPM's of the update are:

msec-0.80.10-2.1.mga1.src.rpm 
sectool-0.9.3-1.1.mga1.src.rpm

Depends on: (none) => 2317

Testing before installing the updates.

After running run-parts /etc/cron.weekly/ I get errors of sendmail being missing.

# run-parts /etc/cron.weekly/
/usr/lib/sendmail: No such file or directory
"/root/dead.letter" 163/6061
. . . message not sent.
[root@localhost ~]# /usr/lib/sendmail: No such file or directory
"/root/dead.letter" 109/6150
. . . message not sent.


Should sendmail be added as a dependency?

AFAIK it's only needed if you want to send the msec report/cronjob results (dead.letter) to an email account. If you happen to have entered a local user for security reports this could be the reason for this.

Also i think i wouldn't be a good idea to add sendmail to every default installation.

After update I get the error mentioned in comment 3

/usr/share/sectool/scheduler/scheduler.py: inconsistent use of tabs and spaces in indentation

That's no real error, only a cosmetics issue.

i586:

A few bits from the results, not sure if they are anything which needs fixing really..

shadow ->
    Warning: Wrong permissions on regular file "/etc/shadow": 440 (User shadow database, required permissions are 400)
    Warning: Wrong permissions on regular file "/etc/gshadow": 440 (Group shadow database, required permissions are 400)
    shadow: WARNING


netserv ->
    Warning: Test netserv has missing dependencies: yum
    netserv: INVALID


permissions ->
    Error: Directory /srv doesn't exist!
    permissions: ERROR


selinux ->
    Warning: Test selinux has missing dependencies: getenforce, pkg(libselinux-python)
    selinux: INVALID


Other than that, lots of results and the original sectool missing message is now gone.

x86_64:

# urpmi --media "Core Updates Testing" msec sectool
Some requested packages cannot be installed:
msec-0.80.10-2.1.mga1.x86_64 (due to unsatisfied sectool)
sectool-0.9.3-1.1.mga1.x86_64 (due to unsatisfied libselinux.so.1()(64bit))
Continue installation anyway? (Y/n) n

this doesn't really provide the info we need.

Dependencies from core/release to be linked:

- gettext-0.18.1.1-2.mga1.x86_64
- lib64gettextmisc-0.18.1.1-2.mga1.x86_64
- lib64selinux1-2.0.78-3.mga1.x86_64
- lib64unistring0-0.9.3-4.mga1.x86_64
- python-rpm-4.8.1-10.mga1.x86_64
- python-selinux-2.0.78-3.mga1.x86_64

and of course the gnome-python-gnomevfs mentioned earlier.



A few of the more interesting results:

group ->
    Warning: /etc/group: Line 30: Group nogroup has GID out of range
    Warning: /etc/group: Line 51: Group xguest has GID out of range
    group: WARNING

passwd ->
    Warning: Wrong permissions on regular file "/etc/shadow": 440 (Shadow user database, required permissions are 400)
    Warning: Wrong permissions on regular file "/etc/gshadow": 440 (Shadow group database, required permissions are 400)
    Error: /etc/passwd: Line 15: User messagebus has strange shell /sbin/nologin
    Error: /etc/passwd: Line 16: User avahi has strange shell /bin/false
    Error: /etc/passwd: Line 17: User avahi-autoipd has strange shell /bin/false
    Error: /etc/passwd: Line 18: User polkituser has strange shell /sbin/nologin
    Error: /etc/passwd: Line 19: User haldaemon has strange shell /sbin/nologin
    Error: /etc/passwd: Line 20: User rpm has strange shell /bin/false
    Error: /etc/passwd: Line 21: User rtkit has strange shell /sbin/nologin
    Error: /etc/passwd: Line 22: User vcsa has strange shell /sbin/nologin
    Error: /etc/passwd: Line 23: User gdm has strange shell /bin/false
    Error: /etc/passwd: Line 24: User htdig has strange shell
    Error: /etc/passwd: Line 26: User mediatomb has strange shell /bin/false
    Error: /etc/passwd: Line 27: User sshd has strange shell /bin/true
    Error: /etc/passwd: Line 30: User xguest has strange shell /bin/rbash
    Error: /etc/passwd: Line 31: User usbmux has strange shell /sbin/nologin
    Error: /etc/passwd: Line 33: User ftp has strange shell /bin/false
    Error: /etc/passwd: Line 35: User ntp has strange shell /bin/false
    Error: /etc/passwd: Line 36: User hsqldb has strange shell /sbin/nologin
    Error: /etc/passwd: Line 37: User boinc has strange shell /sbin/nologin
    Error: /etc/passwd: Line 38: User mpd has strange shell /bin/false
    Error: /etc/passwd: Line 39: User mailnull has strange shell /dev/null
    Error: /etc/passwd: Line 40: User smmsp has strange shell /dev/null
    passwd: ERROR

shadow ->
    Warning: Wrong permissions on regular file "/etc/shadow": 440 (User shadow database, required permissions are 400)
    Warning: Wrong permissions on regular file "/etc/gshadow": 440 (Group shadow database, required permissions are 400)
    Error: /etc/shadow: Line 30: User xguest has no password!
    shadow: ERROR

filesystem ->
    Warning: Symbolic link "/sbin/mount.smb" points to a non-existent file "/etc/alternatives/mount.smb".
    Warning: Symbolic link "/sbin/mount.smbfs" points to a non-existent file "/etc/alternatives/mount.smbfs".
    Warning: File "/etc/sysconfig/desktop" is executable and group writable.
    Warning: File "/etc/sysconfig/compositing-wm" is executable and group writable.
    Warning: File "/etc/sysconfig/compositing-server" is executable and group writable.
    Warning: File "/etc/sysconfig/menustyle" is executable and group writable.
    Warning: File "/etc/sysconfig/network" is executable and group writable.
    Warning: Symbolic link "/etc/alternatives/activation" points to a non-existent file "/usr/share/java/geronimo-jaf-1.0.2-api.jar".
    Warning: File "/etc/mcc.conf" is executable and group writable.

logfiles ->
    Error: File /var/log/messages has wrong permssions! The correct permissions are 600.
    logfiles: ERROR

permissions ->
    Error: Directory /srv doesn't exist!
    permissions: ERROR

selinux ->
    Warning: Test selinux has missing dependencies: getenforce, pkg(libselinux-python)
    selinux: INVALID

mountopt ->
    Warning: The local mountpoint /home is not / but doesn't have "nodev" option set.
    mountopt: WARNING


This is not an exhaustive list of results just the more interesting ones.

Do you think there are any configuration changes needed? Will libselinux-python need adding as a dependency?

(In reply to comment #17)
> Testing before installing the updates.
> 
> After running run-parts /etc/cron.weekly/ I get errors of sendmail being
> missing.
> 
> # run-parts /etc/cron.weekly/
> /usr/lib/sendmail: No such file or directory
> "/root/dead.letter" 163/6061
> . . . message not sent.
> [root@localhost ~]# /usr/lib/sendmail: No such file or directory
> "/root/dead.letter" 109/6150
> . . . message not sent.
> 
> 
> Should sendmail be added as a dependency?

This is a pet peeve of mine. See Bug 1621
https://bugs.mageia.org/show_bug.cgi?id=1621

"Out of the box" Mageia (and Mandriva) cannot deliver security emails.

CC: (none) => derekjenn

sendmail should not be needed for delivery to local user accounts. Also bug 1621 is about the installer and a default install, not directly about msec.

@MrsB: The results of the security checks are not subject to this bugreport. If there is anything wrong about them, then someone more knowledgeable about that matter should investigate this and either adapt the sectool checks or the cause of the reported issues.

Also we don't have libselinux-python, we have python-selinux. So far i'd say this bug is resolved, as msec now requires sectool and sectool has the added dependencies to be able to run.

But sendmail (or alternative) is required for local delivery.
Try it out for yourself

$ mailx -v -s "test mail" root
EOT
/usr/lib/sendmail: No such file or directory
"/home/derek/dead.letter" 9/214
. . . message not sent.

Florian, do you think it would be better to have somebody look at this before it is validated or to open a separate bug report?

It shouldn't block the update but it does really need fixing.

Sorry, I should specify, the sectool configuration.

(In reply to comment #25)
> But sendmail (or alternative) is required for local delivery.

OK, sorry, than my information from back in the days is actually wrong.
I can commit a fix for this, so that msec requires sendmail.

@MrsB: I guess you mean the sendmail issue?   ^^

msec-0.80.10-2.2.mga1 with Require on sendmail should be available soon on mirrors.

(In reply to comment #29)
> msec-0.80.10-2.2.mga1 with Require on sendmail should be available soon on
> mirrors.

Are you serious?!?!

$ urpmq --conflicts sendmail
vacation
postfix

First think then act :/

sendmail -> mail-server

And i'm not sure that we really need mail server for everyone.. This should be asked in dev ml. I vote against it.

Mandriva for example has mailx.

Florian I meant the sectool configuration for Mageia ^^ in comment 27, you said it would need somebody with more knowledge.


Regarding sendmail, msec-gui could maybe be made to offer to install it if/when the box is ticked to send the results by email as a possible solution. IMHO that would be something for another bug though, perhaps bug 1621 as Derek mentioned.

Hmm, mail-server is also bad idea, maybe sendmail-command. I'm not sure.

(In reply to comment #30)
> (In reply to comment #29)
> > msec-0.80.10-2.2.mga1 with Require on sendmail should be available soon on
> > mirrors.
> 
> Are you serious?!?!
> 
> $ urpmq --conflicts sendmail
> vacation
> postfix
> 
> First think then act :/
> 
> sendmail -> mail-server
> 
> And i'm not sure that we really need mail server for everyone.. This should be
> asked in dev ml. I vote against it.
> 
> Mandriva for example has mailx.

Yes, me too is against sendmail for everyone. But seems mailx (part of nail which is already in a default install) requires sendmail, so maybe a bug in nail.

OK, so update testing has to be suspended so far and i'll write to -dev.

@MrsB: Feel free to open up another bugreport about sectool configuration.
About msec-gui requiring another package so it can send the reports, you have to find somebody else to do that, i'm no programmer. If you have a patch for it, i'll happily apply it.

requires: sendmail-command should work and handle the various conflicts


urpmq --whatprovides sendmail-command
sendmail|postfix|ssmtp|dma|msmtp

CC: (none) => stewbintn

Bug 2808 created regarding sectool configuration for mageia

(In reply to comment #34)
> requires: sendmail-command should work and handle the various conflicts
> 
> 
> urpmq --whatprovides sendmail-command
> sendmail|postfix|ssmtp|dma|msmtp

In Bug 1621 I suggested using dma instead of 'requires: sendmail-command' because dma is not a full mail server, and delivers without any configuration.

requires: sendmail-command would present the user with a list to choose from which could lead a novice to install a full mail server.

If a user did require a full mail server installing one would override dma in /etc/alternatives

What is happening with this please?

You can follow the discussion on mageia-dev mailing list, or in the list archives:
https://www.mageia.org/pipermail/mageia-dev/2011-September/008289.html

*** Bug 1621 has been marked as a duplicate of this bug. ***

Ping Florian. Are you ok to implement the solution given by Derek on the mageia-dev mailing list?

CC: (none) => stormi
Assignee: qa-bugs => doktor5000

Already applied, waiting for review. You can take a look here:
http://svnweb.mageia.org/packages/updates/1/msec/current/SPECS/msec.spec?r1=151602&r2=151601&pathrev=151602

What is the status of this update please?

Well, during review it showed out that the changes that were wanted by users are antipodal to each other (enable msec default installation to actually send reports VS disabling reports by default). I've asked for comments, but for now there was only one relevant comment, which would involve changing msec code: https://www.mageia.org/pipermail/mageia-dev/2011-October/008726.html

As i'm no coder, if no patch shows up or no other solution, i guess then we can't disable sending msec reports. I'd wait till next weekend, if no solution shows up we need to push the update without disabling msec sending reports by default.

We cannot push the update to msec with a requires on sendmail, as it
will conflict with postfix and vacation.

A requires on either mail-server or sendmail-command, would be ok.

CC: (none) => davidwhodgins

Was already replaced by a Suggests on dma:
http://svnweb.mageia.org/packages/updates/1/msec/current/SPECS/msec.spec?r1=146547&r2=151602
But as already explained, due to the second change about the default settings, this can't be pushed as-is.

OK, after the discussion seems to have come to an end, no change was done to msec and it was reverted to previous state before discussion. So now the only thing to be validated are the added dependency for sectool and the fix for https://bugs.mageia.org/show_bug.cgi?id=1530 exchanging the blank icon against a valid one.

Need linking at least: 

sectool
sectool-gui
gnome-python-gnomevfs2
python-rpm
drakconf-icons

Update candidate to validate: msec-0.80.10-2.3.mga1


Suggested advisory:

msec, the Mageia security level management, was missing a dependency on sectool, a security auditing and intrusion detection system.
Also a proper update icon was added to msec, replacing the previously blank icon.

i586:

]# urpmi msec msec-gui
To satisfy dependencies, the following packages are going to be installed:
   Package                        Version      Release       Arch   
(medium "Core Release")
  gettext                        0.18.1.1     2.mga1        i586    
  libgettextmisc                 0.18.1.1     2.mga1        i586    
  libselinux1                    2.0.78       3.mga1        i586    
  libunistring0                  0.9.3        4.mga1        i586    
  python-selinux                 2.0.78       3.mga1        i586    
(medium "Core Updates Testing")
  msec                           0.80.10      2.3.mga1      i586    
  msec-gui                       0.80.10      2.3.mga1      i586    
  sectool                        0.9.3        1.1.mga1      i586


Our depcheck script reports..

The following packages will require linking:

gettext-0.18.1.1-2.mga1 (Core Release)
libcroco0.6_3-0.6.2-7.mga1 (Core Release)
libgettextmisc-0.18.1.1-2.mga1 (Core Release)
libgomp1-4.5.2-4.mga1 (Core Release)
libselinux1-2.0.78-3.mga1 (Core Release)
libunistring0-0.9.3-4.mga1 (Core Release)
python-selinux-2.0.78-3.mga1 (Core Release)



In the GUI, clicking to run the manual check it brought up a warning that it may take a long time, then proceeded to do something/nothing and finish instantly. The same for Monthly checks, both of which have apparently never been run. It states that checks were executed successfully but doesn't update when it was last run or allow me to see any results - the button is greyed out.

run-parts /etc/cron.monthly/

was similar with nothing appearing to be done.

# ll /etc/cron.monthly/
total 8
-rwxr-xr-x 1 root root 113 Apr 13  2011 0anacron-timestamp*
lrwxrwxrwx 1 root root  27 Oct 13 21:30 msec -> /usr/share/msec/security.sh*
-rwxr-xr-x 1 root root 111 Mar 16  2011 readahead-monthly.cron*

From /var/log/msec.log when running the cron.monthly

INFO: Checking paths: followed by alot of paths

INFO: Modified system files: /var/log/security/suid_md5.monthly.today
WARNING: Enforcing group on /var/log/security/suid_md5.monthly.today to adm
WARNING: Enforcing permissions on /var/log/security/suid_md5.monthly.today to 640

When clicking to run monthly check in the GUI the log shows only..

2011-10-24 11:05:52,899 WARNING: Enforcing group on /var/log/security/suid_md5.monthly.today to adm
2011-10-24 11:05:52,899 WARNING: Enforcing permissions on /var/log/security/suid_md5.monthly.today to 640


When clicking to run manual checks in the GUI the log shows only..

2011-10-24 11:14:13,574 WARNING: Enforcing group on /var/log/security/suid_md5.manual.today to adm
2011-10-24 11:14:13,575 WARNING: Enforcing permissions on /var/log/security/suid_md5.manual.today to 640

So it appears there is something wrong with those two.


Daily checks work fine, they finish quickly but produce results and update the last run time when opening the gui again.

msec.log

2011-10-24 11:28:42,425 WARNING: Enforcing group on /var/log/security/suid_md5.daily.today to adm
2011-10-24 11:28:42,426 WARNING: Enforcing permissions on /var/log/security/suid_md5.daily.today to 640
2011-10-24 11:28:42,426 WARNING: Enforcing group on /var/log/security/mail.daily.today to adm
2011-10-24 11:28:42,426 WARNING: Enforcing permissions on /var/log/security/mail.daily.today to 640

# ll /etc/cron.daily/
total 32
-rwxr-xr-x 1 root root 109 Apr 13  2011 0anacron-timestamp*
-rwxr-xr-x 1 root root 258 Jul  7 09:27 logrotate*
-rwxr-xr-x 1 root root 410 Jan 10  2011 makewhatis.cron*
-rwxr-xr-x 1 root root 192 Apr  2  2011 mlocate.cron*
lrwxrwxrwx 1 root root  27 Oct 13 21:30 msec -> /usr/share/msec/security.sh*
-rwxr-xr-x 1 root root 563 Mar 16  2011 readahead.cron*
-rwxr-xr-x 1 root root 187 Oct  1 21:39 rkhunter*
-rwxr-xr-x 1 root root 296 Oct  2 02:07 rpm*
-rwxr-xr-x 1 root root 432 Jan 12  2011 tmpwatch*


Weekly check works fine but running it after running the daily checks causes the GUI to lock up with msecgui.py maxing the CPU.

2011-10-24 11:33:42,731 WARNING: Enforcing group on /var/log/security/mail.daily.today to adm
2011-10-24 11:33:42,731 WARNING: Enforcing permissions on /var/log/security/mail.daily.today to 640

Appears in msec.log when the check has completed and desktop notifications pop up to say msec has run but then it locks up.

Normal Kill doesn't work it needs kill -9

# ll /etc/cron.weekly/
total 16
-rwxr-xr-x 1 root root  111 Apr 13  2011 0anacron-timestamp*
-rwxr-xr-x 1 root root 2770 Apr  2  2011 99-raid-check*
-rwxr-xr-x 1 root root  950 Jan 10  2011 makewhatis.cron*
-rwxr-xr-x 1 root root   66 Jan 11  2011 makewhatis-en.cron*
lrwxrwxrwx 1 root root   27 Oct 13 21:30 msec -> /usr/share/msec/security.sh*

There are issues here :\

X86_64

Same symptoms. Locks completely if weekly checks are run directly after daily checks with msecgui.py taking 100% CPU.

Only kill -9 would kill it.

Monthly and Manual check not working.

I havent confirmed if these problems were present before the update so I will check that.

Now it's broken completely.

After reverting back to release version I now get the errors below when running the various checks.

Running /etc/cron.daily/msec
sh: /etc/cron.daily/msec: No such file or directory

Running /etc/cron.weekly/msec
sh: /etc/cron.weekly/msec: No such file or directory

Running /etc/cron.monthly/msec
sh: /etc/cron.monthly/msec: No such file or directory

Running /usr/share/msec/security.sh

After updating again to the testing version it is the same.

Removing msec removes the links 

msec -> /usr/share/msec/security.sh*

They are not recreated when msec is reinstalled.


Once they are added back manually and with msec from release it appears the problem of locking up with msecgui.py taking 100% CPU and the monthly/manual checks are present there too so should be separate bugs.

Related bugs:

Sectool configuration - bug 2808
Update button not working - bug 1619

New bugs:

msecgui.py 100% CPU - bug 3180
Missing links - bug 3181
Monthly/Manual Checks - bug 3182

There is alot wrong with Msec at the moment but it appears all icons are now present and sectool has at least been added.

I think we can validate this now.

The following packages will require linking:

gettext-0.18.1.1-2.mga1 (Core Release)
libcroco0.6_3-0.6.2-7.mga1 (Core Release)
libgettextmisc-0.18.1.1-2.mga1 (Core Release)
libgomp1-4.5.2-4.mga1 (Core Release)
libselinux1-2.0.78-3.mga1 (Core Release)
libunistring0-0.9.3-4.mga1 (Core Release)
python-selinux-2.0.78-3.mga1 (Core Release)

Advisory
---------------------
This update adds the security tool Sectool to Msec and addresses a problem with icons not displaying correctly in Msec GUI.
---------------------

SRPM's: 

msec-0.80.10-2.3.mga1.src.rpm
sectool-0.9.3-1.1.mga1.src.rpm

Could sysadmin please push from core/updates_testing to core/updates and make the required links below for 32 & 64 bit

gettext-0.18.1.1-2.mga1 (Core Release)
libcroco0.6_3-0.6.2-7.mga1 (Core Release)
libgettextmisc-0.18.1.1-2.mga1 (Core Release)
libgomp1-4.5.2-4.mga1 (Core Release)
libselinux1-2.0.78-3.mga1 (Core Release)
libunistring0-0.9.3-4.mga1 (Core Release)
python-selinux-2.0.78-3.mga1 (Core Release)

Thankyou!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Hardware: i586 => All

Please hold the push. Adding depends on Bug 1619 which has had some love :)

Depends on: (none) => 1619

Advisory
---------------------
This update adds the security tool Sectool to Msec and addresses a problem with
icons not displaying correctly in Msec GUI.

It also provides a fix to make the Update Now button work correctly in the GUI.
---------------------

SRPM's: 

msec-0.80.10-2.4.mga1.src.rpm
sectool-0.9.3-1.1.mga1.src.rpm

Could sysadmin please push from core/updates_testing to core/updates and make
the required links below for 32 & 64 bit

gettext-0.18.1.1-2.mga1 (Core Release)
libcroco0.6_3-0.6.2-7.mga1 (Core Release)
libgettextmisc-0.18.1.1-2.mga1 (Core Release)
libgomp1-4.5.2-4.mga1 (Core Release)
libselinux1-2.0.78-3.mga1 (Core Release)
libunistring0-0.9.3-4.mga1 (Core Release)
python-selinux-2.0.78-3.mga1 (Core Release)

Thankyou!

Update pushed.

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED

seems there is a issue with this update: bug 3203

Sorry, the following package cannot be selected:

- msec-0.80.10-2.4.mga1.x86_64

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

libcroco0.6_3-0.6.2-7.mga1 (Core Release) has not been linked.

Can you look please Thomas.
Thanks.

Or any sysadmin :)

Please add the link in comment 57 which has been missed.

We currently have a broken msec update in Mageia 1.

Thankyou.

Currently fixing...

Link fixed and hdlists updated.

Sorry for the breakage.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Thanks Thomas :)

Thanks Thomas and Claire.

Nice job to all of you :)

With due respect to the author of comment #9, I belive msec was much better off with_OUT_ sectool.  In its present state, sectool is BADLY broken.  It whines for pages about file permissions that are exactly as they should be.  It leaves two orphaned gpg-agent processes.  It leaves at least three files or directories cluttering up /tmp.

I intend to remove sectool from my Mageia 1 system, forcibly if necessary.  Until late October, msec function very nicely without sectool.  On my system, I intend that msec will again have that opportunity.  A one-line error message is vastly preferable to multiple pages of sectool's whining and a need to kill orphaned processes and delete orphaned files and/or directories.

CC: (none) => rmriches

I guess the more proper fix would have been to add sectools as a suggests, and fix the check to not complain if sectool is not installed.

@Robert: Could you please send a mail to mageia#dev ml about that issue? I'm also supporting this, as sectool duplicates msec functionality, the default configuration has not been adapted from Fedora to Mageia and so currently it does more harm than being useful.

@Florian: Message sent to the mailing list (minus a couple of typos in comment #64).  Thank you for the suggestion.

(In reply to comment #65)
> I guess the more proper fix would have been to add sectools as a suggests, and
> fix the check to not complain if sectool is not installed.

IIUC sectool plugin is already cleanly separated in msec, so that we can also split it in a subpackage (proposal in attachment). In this way, only the msec-plugin-sectool will requires sectool.

CC: (none) => lmenut

Created attachment 1329 [details]
proposal to split sectool plugin in a subpackage msec-plugin-sectool

I have no logs for sectool since 9 Jan this year, and the log for that date is empty. The entry in logrotate.d has "notifempty." Is this normal, or should I file a bug? sectool.log.1 is 686K, the remaining gzipped ones are about 40K.  The RPM is installed.

CC: (none) => laidlaws

(In reply to comment #70)
> I have no logs for sectool since 9 Jan this year, and the log for that date is
> empty. The entry in logrotate.d has "notifempty." Is this normal, or should I
> file a bug? sectool.log.1 is 686K, the remaining gzipped ones are about 40K. 
> The RPM is installed.

It's now disabled by default, as the default configuration has
not been configured to match msec.

If you want it enabled, use msecgui, and enable CHECK_SECTOOL on
the periodic checks tab.

I never look at the msec logs.  It may be stupid, but I am a solo desktop user. I don't belong here, and will unsubscribe.