Eugeni Dodonov wrote:
> On 02/08/2010 05:27 PM, Fabrice Facorat wrote:
>  
>> As I'm short on time to do a proper blog post with screenshots/mockup.
>> I will told you about the mains improvements I would find interesting
>>  
>
> [...]
>
>  
>> - in shadow check ( CHECK_SHADOW ), I guess that we should ignore
>> xguest user by default ?
>>  
>
> Indeed, I updated msec to handle that.
>
>  
>> You have 3 states :
>>  
> [...]
>  
>> For each categories, you can see the details ( associated report to
>> the security check/plugin ), say to ignore some stuff or mark as fixed
>>  
> [...]
>  
>> So it measn being able to :
>> - query the sate of each security plugin ( could be cool from CLI by
>> using msec --check-plugin ALLOW_ROOT_LOGIN )
>>  
> [...]
>
> Thanks! These were really interesting thoughts.
>
> By the way, this is very very similar to the way RedHat/Fedora's sectool
> works. We have it right now in contrib (in sectool and sectool-gui
> packages).
>
> The difficulty about moving msec into this model are the following:
> - we'll lose the backward compatibility completely (e.g., new msec will
> behave almost completely different from the old msec)
> - it will behave very similarly to sectool. This is not that bad, the
> good part is that we may reuse sectool plugins (sectool core is in
> python as well), but I feel that it will be like reinventing the wheel.
> On the other hand, we perfectly could use sectool plugins instead and
> port msec-specific stuff to the sectool plugin format.
>
> The problem is that me and vdanen talked to the sectool guys last year,
> and it seems that their development attention was completely shifted
> away from sectool. So I am a bit reluctant of working on something that
> seems not to be properly maintained and worked on anymore. So while it
> could be an interested approach, I think we should not rush on it -
> certainly not for 2010.1.
>
> But I completely agree with you - the most important thing to get into
> msec would be an improved UI, which is a long standing item in my TODO
> list. For example, what I have in mind to put into msec at some point in
> the future are things like:
> - allow to run each test or group of tests interactively, from the
> msecgui or console, and display their results using the OK/WARNING/ERROR
> criteria. This can be done easily with current msec.
> - improve security text description for all possible security results.
> For example, instead of "Un-owned files found" it could display
> "Warning: msec has detected files that do not have a local user owning
> them. This could have security implications if a user with matching user
> identifier (ID) is to be created later. In this case, the newly-created
> user could have complete access to such files. To fix this issue, msec
> can specify the user 'nobody' as the owner to those files. This can be
> done by enabling the FIX_UNOWNED option in msecgui"). Of course, such
> messages should be translated.
> - improve msecgui GUI to make it more task-oriented. Your screenshots
> gave me lots of ideas, I'll see if I can get them done :).
>
> Thanks,
>
>  
Just a quick comment on msec. In 2010.0 you ship msec with wheel group
membership to use su set to yes and password for su set the yes.
If you are going to wheel group membership to yes by default you should
enforce membership of this group to use su, and, if you default it to no
you should enforce the membership if the end user changes it to yes.
Current behaviour indicates this would not happen.
In my opinion the use a password for su option should be removed, nobody
should be able to disable the requirement for prompting of the root
password to use su.

regards,
Steve