On 11/05/2012 11:47, ken wrote:
On 11/04/2012 11:29 PM Dave Quigley wrote:
On 11/4/2012 6:03 PM, ken wrote:
It's nice with selinux that a notification window pops up when a
violation has been detected... and then that it's a simple matter
to
click on an icon to pop open a window with much more information.
But
lacking in that window is critical information necessary to
identify and
then perhaps resolve the issue.
Fundamentally the action of some executable has tried, against
policy,
to access some file. So why doesn't this page list:
- the name of the file, including full path, against which access
was
attempted;
- the name of the executable, including full path, which tried to
access
that file; and
-- text explaining the policy which was violated, or at least a
link
to it?
I've had selinux installed for some years now (in permissive mode),
but
am considering uninstalling it because, lacking this obvious and
critical information, there doesn't seem to be a point to it.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
To answer your questions in order
1) It will give you the name of the target file. However unless you
have
full syscall auditing turned on the audit subsystem doesn't have the
full path information. You could turn it on but it introduces some
overhead. To do this you just have to include one rule with auditctl
or
you can put it in /etc/audit/audit.rules
What rule-- what text do I type in /etc/audit/audit.rules to turn on
full syscall auditing?
It doesn't have to be a specific rule. Full path auditing gets turned
on when any audit rule is present. By default Fedora/RHEL ship with 0
audit rules in place so the full path auditing is off. You could do a
watch for write on shadow for example which i think is auditctl -w
/etc/shadow. I have it in my slides but I don't remember it off hand.
2) It tells you the program that tried the access it is in the comm
and
exe field of the AVC audit message. Comm will be just the command
and
exe will be the full path.
Thanks, I found that (in the small print at the very bottom). Given
the importance of this particularly piece of information, I was
thinking it would be displayed much more prominently and
unambiguously.
It should also be in the show details part in setroubleshoot-applet. I
believe it gives you all the needed information in there but if it
doesn't then reading the raw AVC denial message has everything you'd
need to figure out the problem.
3) The policy it violated was that it attempted an access that isn't
in
policy. SELinux is deny by default. It will tell you what access it
attempted. The avc record will start with denied { permission } then
will specify scontext which is the source context, tcontext which is
the
target context, and tclass is the object class.
Thanks for this too. But I have to admit that those terms are
meaningless to me, along with the values they're given in audit
messages I've read. I've written quite a bit code in my time, so I
know it's part of being a developer that we understand an application
so well, we begin to think that everyone else in the world must also.
And/Or we figure that someone else will write a manual or a manpage
that will clarify everything and make our app usable.
Maybe if some new developers come along, they'd see opportunities for
further development, so instead of the arcane language in the Raw
Audit Messages, we'd get a human-readable explanation of why an
operation isn't permitted and its potential dangers, and then
checkboxes to click on to allow one-time execution, execution for the
current session, or execution from now on. Something like that....
The terms above form the foundation of the access control model used by
SELinux.
The idea is that SELinux policy is the set of actions allowed in the
computer. Every process is given a security context (or label) and every
object in the system is given the same. The rules says how can a process
labeled with one label for example apache (httpd_t) interact with some
object in the system for example index.html (httpd_sys_content_t).
The basic form of a rule is:
Source target object_class: {Permissions}
Three of those terms should be clear now. The object_class part can be
confusing at first but allows SELinux to be a very powerful access
control mechanism. The object class field allows us to differentiate
between different types of objects in a system (files, directories,
sockets, block devices, character devices, etc...) The benefit of this
is that it allows for rules to be written to differentiate write to a
socket and write to a file differently. So in the apache accessing a
file example above you get something like: httpd_t httpd_sys_content_t
file:{read}.
Hopefully that helps explain a couple of things. With respect to man
pages Dan Walsh and his co-workers at Red Hat are doing an amazing job
with adding man pages not just for all the SELinux applications and
Libraries but also for policy itself. He has added man pages for every
single domain in the policy so you can undertstand what its types are
and how it expects to access them.
Lastly we've shied away from a click to allow this access model because
we believe its dangerous. An end user doesn't really know what the
reason behind an AVC denial means. Also while setroubleshoot gives you
suggestions they are a best effort solution. It might be possible that
there are multiple solutions (local policy module vs a policy boolean).
Regardless of that fact there is always room for usability improvements
and the many developers working on SELinux have been making improvements
in that area for a long time. Its a difficult problem but there has
definitely been a lot of progress from when I first started using Fedora
Core 2.
Dave
Dave
Thanks again for your explanations.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
