Description of problem: When running level 3 and higher tests, it never finishes. With --debug, you see that its in home_files test and appears to finish testing root. Then getting the next user, it outputs: testing user "systderr from filesystem: find: '/libexec' : No such file or directory stderr from filesystem: /usr/bin/stat: cannot stat '/tmp/sh-thd-1210787222' : No such file or directory There is no closing double-quote. Running strace shows its looping between select and wait4. Version-Release number of selected component (if applicable): 0.7.3-1.fc10 How reproducible: every time Steps to Reproduce: 1. sectool --level 3
Both home_files and running a level work for me fine.. Can you please re-run without the home_files test (sectool --level 3 --exclude home_files). Can you check that the test is still running after sectool "freezes"? (just ps aux | grep home_files.sh)
I upgraded some packages yesterday. Today its acting better. I no longer see the bad user name. When it "hangs" now, I ran ps and see that its executing sh /usr/share/sectool/tests/filesystem I see it looping over and over doing something with files. But the text on the screen is half finished looking like it broke. Maybe it needs a fflush of stdout to get the screen updated with what its really doing. Also maybe a warning about this test taking a while to run is in order? In the filesystem test, I see a message that says a file is world/group writable. Its only group writable, not world writable. There is a big difference security-wise between world and group writable. :) The message should reflect what it really is. The selinux test says its disabled or in the wrong mode. What's wrong about permissive? I think the message should say what mode its in and not be vague about it. Permissive is slightly better than disabled, but its not wrong. :) It also still can't differentiate between symlinks and files when it reports world writable in the alias test. Alias halt is a good example since poweroff is a symlink. I wanted to give you feedback on a level 5 run too, but its been running for 2-3 hours now in the filesystem test. I'll give more feedback when it finally finishes. I have a feeling this should be a C program and not shell scripts. :)
(In reply to comment #2) > I upgraded some packages yesterday. Today its acting better. I no longer see the > bad user name. > > When it "hangs" now, I ran ps and see that its executing sh > /usr/share/sectool/tests/filesystem > > I see it looping over and over doing something with files. But the text on the > screen is half finished looking like it broke. Maybe it needs a fflush of stdout > to get the screen updated with what its really doing. Also maybe a warning about > this test taking a while to run is in order? > > In the filesystem test, I see a message that says a file is world/group > writable. Its only group writable, not world writable. There is a big difference > security-wise between world and group writable. :) The message should reflect > what it really is. Could you please post the exact message? The world/group message should appear only if the file is world/group writable AND world/group executable - and that is IMHO ok, because a executable file shouldn't be writable for a group - unless you trust everyone in the group :]. There is separate test for world-writable files and dirs. > The selinux test says its disabled or in the wrong mode. What's wrong about > permissive? I think the message should say what mode its in and not be vague > about it. Permissive is slightly better than disabled, but its not wrong. :) > > It also still can't differentiate between symlinks and files when it reports > world writable in the alias test. Alias halt is a good example since poweroff is > a symlink. > > I wanted to give you feedback on a level 5 run too, but its been running for 2-3 > hours now in the filesystem test. I'll give more feedback when it finally > finishes. I have a feeling this should be a C program and not shell scripts. :) Yes. I'm rewriting it to C now.
ad aliases: it is now fixed in git
sectool-0.7.4-2.fc9 has been submitted as an update for Fedora 9
sectool-0.7.4-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.