file, executable, and policy

[David Quigley]

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 at lists.fedoraproject.org
>>> 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.