I found that root.ctools 710 is set by msec when using the 'secure' level. But changing the level back to 'standard' doesn't fix permissions, despite what msec says (it explicitly mentions that permissions will be set back to root.root 755). So kernel is not the culprit; it's msec.

Summary: /boot is no longer readable (permissions are root.ctools 710 instead of root.root 755) => Setting the security level from 'secure' to 'standard' in msec doesn't fix /boot permissions (permissions are root.ctools 710 instead of root.root 755)

I see another problem:

when you click "sauvegarder la configuration" (save configuration), the popup window says "sauvegarder et appliquer la nouvelle configuration" (save and execute the new configuration), except that nothing is executed, AFAIK. You have ton run cron.daily to see something happen.

Can someone confirm?

Did you run msecperms -e after changing security levels?

It could be that the explicit permissions wanted in standard isn't listed in perm.standard, so the fix would be to add it in there.

(In reply to David Walser from comment #3)
> Did you run msecperms -e after changing security levels?

I didn't. As I said in comment 2, msec is supposed to do it itself when saving changes, or the text displayed in the window when saving changes is wrong.

Running msecperms lists a tons of wrong permissions. Running msecperms -e fixes the problem.

In /usr/share/msec/scripts/01_files.sh, I see that it looks at CHECK_PERMS and CHECK_PERMS_ENFORCE to know if it should fix permissions, but they are both set to 'no' in /etc/security/msec/level.standard, which is why permissions are not fixed when running /etc/cron.daily/msec. I understand that the goal is to ignore changes made manually, but shouldn't they be ignored when editing the security level, i.e. that there should be a one-time check & fix?


> It could be that the explicit permissions wanted in standard isn't listed in
> perm.standard, so the fix would be to add it in there.

This part is fine, /boot is listed there.

Hello, 
Seeing the code in http://gitweb.mageia.org/software/msec/tree/src/msec/msecgui.py#n433
I confirm that when saving the new settings from menu, the program:
- saves the base_level (standard, secure...)
- applies each rule of the new level (function apply)
- writes files with the new settings of rules
- WRITES PERMISSIONS CONFIGURATION in file WITHOUT APPLYING THEM.

Is this behaviour expected? I didn't find recent changes on that.
For /boot in permissions rules, "force" is not checked.

CC: (none) => yves.brungard_mageia

If we want that the user has the choice to apply the new settings on permissions, we can add a check box to enable it or not in the dialog box to confirm saving the settings.
If checked, the tool launches "msecperms -e" or equivalent.
What do you mean about that?

(In reply to papoteur from comment #6)
> If we want that the user has the choice to apply the new settings on
> permissions, we can add a check box to enable it or not in the dialog box to
> confirm saving the settings.
> If checked, the tool launches "msecperms -e" or equivalent.
> What do you mean about that?
Hello,
I need some feedback on that.
And if this proposition is accepted, can we apply it in Mageia 6 or only in cauldron?

(In reply to papoteur from comment #6)
> If we want that the user has the choice to apply the new settings on
> permissions, we can add a check box to enable it or not in the dialog box to
> confirm saving the settings.
> If checked, the tool launches "msecperms -e" or equivalent.
> What do you mean about that?

I think that's a good idea.