Description of problem: msec in "secure" setting ignores custom rules added for files and directories Adding a file permission rule using msec GUI doesn't change msec daily check behaviour. Changing /etc/security/msec/perms.conf doesn't seem to affect msec checks. Appending the rule manually to /etc/security/msed/perm.secure changes the behaviour. Rule in question: /var/log/munin/ root.root 750 "force" doesn't matter, as well as user/group spec. msec.daily doesn't seem to complain about /mnt after adding this rule manually (could be due to other effects): /mnt/ root.adm 755 Version-Release number of selected component (if applicable): msec-0.80.10-10.mga2.src.rpm How reproducible: Always Steps to Reproduce: 1. Set msec to "secure" 2. Add abovementioned munin permissions rule 3. Change permissions on /var/log/munin manually 4. Observe 700 permissions forced at msecperms -e run
Assignee: bugsquad => cazzaniga.sandro
Go on my todo list, I'll take a look as soon as possible and let you know the progression.
Did you try to edit /etc/security/msec/perm.local to add your customs permissions?
Status: NEW => ASSIGNED
I moved the munin rule from /etc/security/msec/perms.conf to /etc/security/msec/perm/local. Here's what happened: [root@gateway msec]# msecperms -e INFO: Modified system files: /usr/bin/who /var/log/munin /mnt WARNING: Enforcing permissions on /usr/bin/who to 751 WARNING: Enforcing permissions on /var/log/munin to 750 WARNING: Enforcing permissions on /mnt to 755 [root@gateway msec]# msecperms -e INFO: Modified system files: /var/log/munin WARNING: Enforcing permissions on /var/log/munin to 700 During the first run the munin rule was appended to perms.conf all perms.conf rules were applied. During the second and following runs the contents of perms.conf were not changed.
(In reply to comment #3) > I moved the munin rule from /etc/security/msec/perms.conf to > /etc/security/msec/perm/local. > I hope you want to say /etc/security/msec/perm.local? :)
Yes, this is a typo :)
So the permissions didn't stay to your local setting?
Permissions on who and /mnt stayed, but /var/log/munin didn't.
Did you have something in msec log?
I can't find anything relevant in the logs.
Can someone help? I don't see anything in the code (class Config) that can make this behavior happened.
(In reply to comment #10) > Can someone help? I don't see anything in the code (class Config) that can make > this behavior happened. Oops, in fact the file is config.py, specially class MsecConfig.
I didn't know msec was not written in perl... Can you point me to the file? I'll fix this when I find a while.
The file is msec/trunk/src/msec/config.py Thanks! :)
Here are my findings: The files that get loaded are: /etc/security/msec/perms.conf /etc/security/msec/perm.secure /etc/security/msec/perm.local My perm.local is empty, so I will ignore it. I found that PermConfig instance holding perms.conf gets updated with perm.secure This is all fine, but perm.secure rules are appended *after* perms.conf. The result: [...] custom rule for /var/log/munin from perms.conf [...] builtin rule for /var/log/* from perm.secure [...] I didn't look farther than that, but it appears that the applying part of msec applies rules in that order - judging from debug info. My rule would get applied, but the overwritten anyway. I think that rules added using the GUI should override builtin rules, but I'm not sure what the general idea was.
(In reply to rh hn from comment #14) > I think that rules added using the GUI should override builtin rules, but > I'm not sure what the general idea was. I don't know... Maybe a msec developper can help on this question?
Whiteboard: (none) => NEEDHELP
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: ASSIGNED => RESOLVEDResolution: (none) => OLD