Assigning to maintainer now that our maintainers database has an entry for
this package. Please assign back to bugsquad@mageia.org in case of a mistake
from me.

CC: (none) => stormi
Assignee: bugsquad => ennael1

Yes, it would be nice if it could parse msec configurations and not complain about things that match what msec is enforcing.  I suppose that would require a patch as msec and sectool upstreams are different.  Speaking of which, if your msec configuration is at the secure level, shouldn't sectool's configuration be set to level 4?

For things like ownership/permissions that aren't enforced by msec, it probably shouldn't complain about things that are as they were packaged, which could be fixed upstream.

It shouldn't complain about missing yum, as that's not appropriate on Mandriva.

It also should not complain about system user accounts (UID < 500).  That should be reported and fixed upstream.

CC: (none) => luigiwalser

CC'ing msec maintainer.

CC: (none) => dmorganec

As dmorgan is currently working on systemd/java for the upcoming Mageia 2, i think we have to find somebody else who can work on this. Either this, or just drop sectool as it is not properly integrated and AFAICS it does not offer advantages over msec, only adds duplicate checks so far.

I have no objection to dropping sectool.

I would second the motion to drop sectool.  In its present state, it is BADLY broken.  It issues pages of whining 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.

CC: (none) => rmriches

IWhat is a status of this bug?

Now on i586 box (Mageia2-alpha2) I have an error message

A requested package cannot be installed:
sectool-0.9.5-2.mga2.i586 (due to unsatisfied python-slip-dbus)

and there are no simple way to remove it 

# urpme sectool
To satisfy dependencies, the following 3 packages will be removed (2.3MB):
  msec-0.80.10-4.mga2.i586
   (due to missing sectool)
  msec-gui-0.80.10-4.mga2.i586
   (due to missing msec)
  sectool-0.9.3-1.mga2.i586
Remove 3 packages? (y/N)

CC: (none) => palm_pre_stl

Try this:

    rpm --test -ev --nodeps sectool

If there are no complaints, repeat the command without the --test option.  According to my notes, that's what I did on November 19.

i added sectool as suggests so you can remove it. And i disabled checktool check by default. 

Please test

Assignee: dmorganec => qa-bugs

Confirmed msec works correctly and doesn't run sectool on i586.

Note to QA: we are testing the same update candidate from Bug 3284

This bug should not be closed until sectool has been properly configured for Mageia as it was imported with Fedora defaults.

Sectool itself has not been updated. AFAIK just removed as a require of msec and added as a suggest.

(In reply to comment #11)
> This bug should not be closed until sectool has been properly configured for
> Mageia as it was imported with Fedora defaults.
> 
> Sectool itself has not been updated. AFAIK just removed as a require of msec
> and added as a suggest.

OK, but bug 3284 can be closed once the update is validated.  I seriously doubt sectool is going to be fixed unless upstream decides to do it.  There doesn't seem to be any interest and it's mostly redundant with what msec already does.

Yes it can.

As for sectool, it's unlikely that fedora will provide us a ready made configuration for Mageia, that will be down to us.

Assigning this sectool bug back to dmorgan as sectool has not been updated so nothing to QA.

(I think it was dmorgan before, sorry if it wasn't!)

Assignee: qa-bugs => dmorganec

Additional errors related to msec integration.

ERROR: Unable to load configuration file /etc/security/msec/perm.audit_weekly.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_weekly.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.netbook.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.netbook.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.audit_daily.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_daily.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.secure.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.secure.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.webserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.webserver.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.fileserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.fileserver.sectool'
ERROR: Unable to load configuration file /etc/security/msec/perm.standard.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.standard.sectool'

(In reply to comment #15)
> Additional errors related to msec integration.
> 
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.audit_weekly.sectool: [Errno 2] No such file or
> directory: '/etc/security/msec/perm.audit_weekly.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.netbook.sectool: [Errno 2] No such file or directory:
> '/etc/security/msec/perm.netbook.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.audit_daily.sectool: [Errno 2] No such file or
> directory: '/etc/security/msec/perm.audit_daily.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.secure.sectool: [Errno 2] No such file or directory:
> '/etc/security/msec/perm.secure.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.webserver.sectool: [Errno 2] No such file or directory:
> '/etc/security/msec/perm.webserver.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.fileserver.sectool: [Errno 2] No such file or
> directory: '/etc/security/msec/perm.fileserver.sectool'
> ERROR: Unable to load configuration file
> /etc/security/msec/perm.standard.sectool: [Errno 2] No such file or directory:
> '/etc/security/msec/perm.standard.sectool'

Just so it's clear, those are spit out by msec-gui, as noted here: https://bugs.mageia.org/show_bug.cgi?id=3284#c11

see also bug 4077

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

CC: (none) => xuoy

3-monthly ping

CC: (none) => marja11

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Seems still valid in mga2

Version: 1 => 2
Whiteboard: (none) => MGA1TOO

Hi,

I think Bug 4516 (https://bugs.mageia.org/show_bug.cgi?id=4516) should be added to this one. Part 2 of this bug description is really boring.

Regards.

Xuo.

And I confirm Bug 4077 is still relevant.

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

From duplicate 4516:

https://bugs.mageia.org/show_bug.cgi?id=4516#c0

> Hi,
> 
> I use msec with "secure" level.
> 1) The /mnt directory has 755 permissions. sectool complains because the
> permissions should be 755 !!
> 2) cron.daily looks into /net/<hostname>. 
> I think this should be avoided as /net/<hostname> is a specific samba mount
> point and belongs to a remote host.
> Ex : //net/ordi3/home/eric/.thunderbird/lpvryr49.default/OfflineCache':
> Permission denied.
> 
> Regards.
> 
> Xuo.

Summary: Sectool Configuration for Mageia => Sectool not configured for Mageia

I have been using sectool with Mageia 3 RC.  I really like it, but it is full of bugs.  Many of these bugs and incompatibilities with Mageia can be addressed by tweaking the various config files in /etc/sectool.  Many are hard coded into sectool in python and would require some degree of script programing to fix.  I have attempted to go upstream to Red Hat/Fedora for help, but their answer is that sectool is currently unmaintained as they have shifted their efforts to OSCAP which is much more sophisticated and complex than sectool.  I hope that sectool continues to be included in the Mageia repository, BUT there should be a warning in the application summary that is presented by rpmdrake that sectool is NOT officially supported by Mageia AND that it is not configured out of the box to work with Mageia.  Those are my thoughts.  I plan to continue using sectool and will be attempting to fix those deficiencies that cause me a problem.

CC: (none) => george

Feel free to submit patches for sectool to fix issues in Mageia to us.  We can include them in our package.  Long term we should probably drop this package though, if it is unmaintained upstream.

David, I am working on sectool.  I discovered that the guts of the sectool tests are written in bash script, not in python.  I suspect python has more to do with the sectool-gui.  I have been able to clean up a quite a few of the false positive stuff already.  For example, sectool was complaining about not being able to find "cd" in /usr/bin or /usr/sbin.  So I inserted a test to eliminate bash builtins by default.  Additionally, I modified the passwd file check to reflect a modern shadow structure with permissions of 440 root:shadow as opposed to the old 400 root:root structure.  I am now getting satisfactory runs on these tests.  But I will need some help from time to time.  At this point I have a simple question.  /etc/shells file is a list of all the valid shells.  So ... what about /sbin/nologin and /bin/false, the "fake shells"?  Should they be included in /etc/shells?  Or should sectool simply be ignoring them?  I have already stopped sectool from checking the GID for nogroup since it is always by definition "invalid" in the nix world.  But where is the problem with the fake shells?  Is it a problem with /etc/shells?  Or is is indeed a sectool problem?  When I get through with this, I will pass these scripts and config files back up to you to look over.  I am carefully noting the changes I make with infile comments.  - George

According to "man -s 5 shells" /etc/shells should only include valid login shells, so it shouldn't have nologin, false, or true.  sectool probably shouldn't complain about them though, but I don't remember what its exact complaint is.

Thanks,  That was kind of my assumption, and after posting the question to you, I noticed that sectool was exempting some users from the test.  So I just added ALL the system accounts not listed on to those exemptions and sectool becomes silent.

The system users you see on your system will vary from others, as it depends on what software you have installed.  Maybe it should ignore all system users (UID < UID_MIN as defined in /etc/login.defs).

The way system users are often determined in sectool is via a list which is rather klutzy.  For some tests they put that list in the config file, for other tests they put it in the bash script.  For still other tests they simply ignore anything with a UID of between 2 and 499 which seems like the right way to do it in the first place.  The list method is really going to be high maintainance going forward, so this whole thing needs to be modified to use the UID method of exclusion I suppose.

Yes, especially since the MIN_UID has actually changed on Fedora from 500 to 1000, so it really should be reading it from login.defs.

Well, after the first surprise over the system account issue, I just got a second little surprise.  I decided to take a closer look at the "integrity" test.  I am pretty certain that I see what the author of the code is trying to do.  But when I in insert a "set -vx" at the top and run the script it becomes pretty clear that even the unmodified script is not doing what it is supposed to be doing.  So, up to now my concern has been about dealing with false positives, but now I'm really starting to wonder about false negatives.  Someone I very much respect has also indicated to me that he has tried to work on this app in the past and found it to be something of a can of worms that just gets darker and darker the deeper you stick your fingers.  Those were not his exact words, but it was the impression I got from his comments.  So at this point, I can indeed see why some around here feel it is better to just euthanize this thing and get over with it.

(In reply to George Mitchell from comment #34)
> Someone I very much respect has also indicated to me that he has
> tried to work on this app in the past and found it to be something of a can
> of worms that just gets darker and darker the deeper you stick your fingers.
> Those were not his exact words, but it was the impression I got from his
> comments.

My comments were about the situation around sectool/msec and the amount of work related to that, not about the actual software itself, i didn't have a close look and also didn't use it, so can't tell anything about its quality.

Anyways, if it's not configured for Mageia, and unmaintained upstream, i also vote for dropping it. FWIW, we should also remove it from msec in that case.

Created attachment 3920 [details]
Test run of sectool on msec

I have been working on sectool as time has permitted over the last few weeks.  So now I just enabled sectool in msec to see how things would work out.  Overall I am pretty happy with the results. The first run actually provided some useful information.  I was unaware of the .config directory planted at / level for example and this run caught that.  At this point I have tried to fix false positives in all the modules except the "filesystem" module which is a binary.  I have just started working out the false negative issues and have completed that task with the initial "system integrity" module by checking the module step by step and making sure it is doing what it claims to be doing.  I basically found it to be unstable as written and missing important checks that it was supposed to be doing, so I made significant modifications in it and now it works flawlessly and it tuned to Mageia 3.  My plan is to do this step by step on each module that is supported by my system (I can't do the selinux module because I don't use selinux for example).  I also plan to rewrite the core module "filesystem" in bash script and completely test it out as well.  I will upload patches as I reach a point where doing so makes sense.  In the mean time I will keep you posted periodically as to my progress.

If you have something ready that should be migrated into our sectool package, just leave a comment here and i'll have a look.

Assignee: dmorganec => doktor5000
Status: NEW => ASSIGNED

Created attachment 3926 [details]
config file for first module

Created attachment 3927 [details]
bash script file for first module

Just to be clear, in the bash script I uploaded, I noted within the script by way of comment that I had made changes in it and also included the date.  As far as the config file is concerned I simply made the changes without notation since it is, in fact, a config file and is intended to be edited.  The version I submitted is simply my suggestion for a default Mageia 3 config file.  Users can customize from that point on.  I think it is also important for users to be aware that the actual modules are bash scripts so any user who knows how to write bash scripts can customize those as well, not to mention, add their own.  The filesystem binary is the fly in the ointment in that regard and as I noted above, I am going to try to find time to replace that with a bash script that won't be quite as fast, but will be far more maintainable.  I will be happy to hear any feedback from anyone.

For anyone who encounters problems with sectool on msec, I would suggest simply stopping the offending module from running by removing the test level in question from the config file for that module.  That should stop that module from running under msec.  The default test level for msec is 3.  I changed it to 2 on my system because I am not networked other than accessing the Internet through a system firewall AND an external router firewall.  I think that makes it safe to test only at level 2.  Of course, each user has to figure that out for their own situation.

Created attachment 3936 [details]
Found and fixed another problem in the integrity test

Created attachment 3937 [details]
bootloader config file modified for Mageia

The bash script file for the bootloader test has no problems that I could find.  The config file needed to be modified to reflect the correct bootloader location.

Created attachment 3938 [details]
bootloader config file modified for Mageia AND to include BOTH grub AND grub2

I realized after I uploaded the previous version that this was an obvious issue so I fixed it.  It needs the modified bash file component to work.

Created attachment 3939 [details]
Modified bootloader script to support either or both grub and grub2 on same machine

This script is designed so that if it detects either or both grub versions, it will run the tests it was initially designed to run.

Created attachment 3940 [details]
Fixed "info" portion of bootloader config file to reflect previous changes

Created attachment 3941 [details]
group config file modified to reflect added /etc/group test

The original author of this test marked as a todo a test to check on an unprivileged user having GID 0.  This test is now included.

Created attachment 3942 [details]
group bash script file modified to ignore nogroup invalid GID and test for extra GID 0

I have modified this test to remove a bogus warning about invalid group regarding nogroup with by definition has an invalid GID.  I also added a test proposed by the original author identifying and warning about any group other than root having root's GID 0.  I have also obseleted several previous patches that have been obseleted by newer versions.

Attachment 3938 is obsolete: 0 => 1
Attachment 3927 is obsolete: 0 => 1
Attachment 3937 is obsolete: 0 => 1

These files come in pairs.  The config file is located in /etc/sectool/tests and always has the suffix .dsc .  The shell scripts are located in /usr/share/sectool/tests and carry the suffix .sh simply because they are shell scripts.  Anyone wanting to snatch any of these and experiment with them is welcome to.  I invite any comments, critiques, complaints, etc anyone might have.

Created attachment 3943 [details]
group bash script file fixes plus nogroup and GID zero enhancements

I added additional support for detection of unpriveleged groups assigned to GID 0 reserved for root and also modified some things that were probably OK the way they were but were making me nervous.  I prefer code to be dependable even if it occasionally sacrifices simplicity and added some brackets in places I thought they were justified.  - George

Attachment 3942 is obsolete: 0 => 1

Created attachment 3944 [details]
passwd bash script - made minor changes, fixed file permissions test to match msec

Made some minor changes to this script.  I fixed the file permissions test to match msec standard.  I also changed the way the script identifies user login accounts as opposed to system accounts so that it is keyed to /etc/login.defs rather than being hard coded in.  I also, as with the other scripts, tested every possible scenario on my system to verify that the tests DO work and that there are no false negatives from a failed test routine.  False positives are more difficult to test, for that I will have to depend on user feedback. But I am seeing no false positives on any of these scripts I have worked on with my system.

Created attachment 3946 [details]
passwd config file modified to reflect msec permissions

Just a modification of the notes to this file.  Nothing more.

Created attachment 3947 [details]
shadow config file modified to reflect added test of passwd hash length

The description in this config file is modified to reflect the additional test of proper passwd hash sum lengths.

Created attachment 3948 [details]
shadow bash script has a number of minor fixes plus a new passwd hash test

This patch includes a new check of passwd hash length the the original author was apparently planning and never implemented.  Also included are modifications of permission checks to make them consistent with msec.  Other minor fixes to make the coding more precise and to eliminate confusing error messages.  For example, a line missing a username will now only include the "missing username" error, not an additional bogus "illegal characters in username" error.

Created attachment 3952 [details]
bash_defs bash script - added file and msec security level support to bash_defs

bash_defs now passes paths for /etc/passwd /etc/shadow /etc/group and /etc/gshadow to the test scripts.  bash_defs also now passes the current msec level to the test scripts.

Created attachment 3953 [details]
home_dirs config file - now reflects and supports major changes to home_dirs bash script

New info descriptions and options to support rewrite of home_dirs test script

Created attachment 3954 [details]
home_dirs bash script - major changes in this test

The home_dirs script checks the user home directories. 1) This script now automatically determines user accounts from /etc/login.defs. 2) All support of tracking of home directory permissions has been removed.  I suggest anyone wanting this sort of information install an application that is designed for that sort of thing from the ground up such as AIDE.  msec is also positioned to do a better job of this than sectools.  3) home_dirs now looks for hidden "." files in the home directories that don't belong their.  It continues to allow the users to whitelist home directories via the config file.  4) home_dirs now does not check for world access and read permission to home directories but offers it as an option via the config file.  5) Support for finding user accounts assigned to root's UID 0 has been removed.  That is done by other test within the suite. I have tested this module rigorously for false positives and for false negatives and at this point feel it is ready to face the world.  If any problems are encountered with it, please let me know.

Created attachment 3963 [details]
root_dirs bash script - modified to stop reporting KDE .config directory at top level

There is some sort of KDE bug that is causing a KDE .config directory to be created at top level.  This patch stops sectool from reporting that directory.  It will need to be relooked at later on. But no need to keep reporting it over and over at this point.

Created attachment 3964 [details]
root_dirs config file to make note of /.config directory exception

(changing version for eol)

Version: 2 => 3

(In reply to George Mitchell from comment #28)
> David, I am working on sectool.

Hi George. Would it be possible to get your work submitted upstream? https://fedorahosted.org/sectool/

Also, do you have commit rights to Mageia SVN?

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=2255
Status: ASSIGNED => NEW
URL: https://bugs.mageia.org/show_bug.cgi?id=2255 => (none)

Florian, My apologies for taking so long to get back on this one.  My problem with this has been that I am basically a shell programmer.  I did some C and other languages back in the PDP 1170 days, but programming has changed since then and I've gotten a lot older and a lot less able to take on major projects.  I found a lot of errors in the redhat scripts for sectool and most of the guts of sectool are actually shell scripts.  But I soon came to the conclusion that mastering SVN was just too much of a leap for me at this point.  So I really, really like sectool, especially for its very versatile modular format, but other than contributing raw shell script, its quite beyond me.  That's why I uploaded all of this shell script here unawares that everything needs to be SVN formatted.  I certainly understand the reasons behind SVN, things really are madness without it.  But for me it is really too much to master.  Sorry, I know this is not the answer you were looking for and I really appreciate your past offers to help me with this, but this is the sad reality for me.

It seems we still (M6) offer sectool, despite it being unmaintained upstream for years. Is this bug still of interest?

CC: (none) => lewyssmith

If sectool is dead upstream, we should just drop it.  I think RHEL has switched to installation profiles and Ansible roles and stuff.  An Ansible-based msec could be a fun development project for someone.

Comment 4 comment 5 comment 6 are pretty conclusive about dropping sectool. From 2012!
Comment 26 comment 27 (2013) introduce 'not supported' upstream.
George Mitchell did a huge amount of work, but things fizzled out in comment 60 comment 61 in 2014 - 5 years ago.
So how do we drop this (from Mageia 7) ?  It would mean dropping also 'sectool-gui' :
 $ urpmq --whatrequires sectool | uniq
 sectool
 sectool-gui

We might need to be careful about msec :
 $ urpmq --requires msec | grep sectool
 $
but
 $ urpmq --requires-recursive msec | grep sectool
 sectool

Jani has dropped sectool in Cauldron.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED