Somebody in the thread at some point said: >>> With traditional unix security a few >>> simple checks can determine the status and any similar problem reported >>> to this list would have an immediate response with the fix or a test to >>> identify the problem. With this, we not only do not have an answer, in >>> the months this thread has continued, not only is there not a fix, no >>> one has produced a diagnostic test to even identify the issue. >> >> I don't agree, the OP simply doesn't follow instructions and so in >> capable of assisting with remote diagnosis. > > But there haven't been any instructions other than handwaving about > reading and interpreting obscure logs. What specific test was suggested > that he failed to run? I recently once more tried Gnome as my desktop as I periodically do, it is much better than last time. One of the things it runs automatically, which KDE didn't AFAICT, is a tray app called setroubleshooter. If an AVC is seen, it pops up a GUI discussing it and the actions you might want to take, listing AVCs it has seen with counts and dates. On "instructions", FOSS support trying to fix some random problem from some random person over the Internet whose machine you will never see is a cooperative venture. If the other half of it just wants to moan about it or 'prove' something then nothing is going to get fixed. Sometimes you come across a guy with a problem and he is as keen as mustard to fix it, truly grip the cause and flow of it soup to nuts, will do difficult tests and report clearly, it's a real pleasure working with them (and not least fully sharing that understanding and education if you succeed). And sometimes there is no goal or point because the guy already figures he "knows" what the "problem" is, but there is no story about how or why and he doesn't even want one, in case it conflicts with the Only True Version from "the bible". >>> How are you supposed to determine the 'correctness' of a given setup? >> >> I don't understand what you mean by this. > > If I asked how to determine whether or not some particular access would > be permitted or denied by the traditional unix mechanism you wouldn't > have any trouble describing how to verify it in terms of permissions > down the file path. I'm asking the same question about SELinux. > > How, for example, would you determine if some change will make it > necessary to relabel? How, other than running something and letting it > fail to get the log message, do you positively determine that some > specific access will be permitted or denied? If you can't see the pam config or resolv.conf on an unknown box you don't know what will work either until you start trying and look. Permissive was useful for me to gingerly add selinux to a remote box that never had it before, the box couldn't be killed but I could learn where the issues were (a handful, FWIW). I turned it straight to enforcing and rebooted and fixed them up. The one golden rule I found seems to be to do with avoiding mv and using cp when introducing files to a new selinux directory tree. So if you created files in ~ and mv them to /var/www/html, because it is done by shifting inodes around and not creating files, they will retain the home directory related selinux label and make trouble. If you cp'd them over, new files are created in the new directory context, they will have httpd-related labels. -Andy
