Re: secilc: is anyone able to confirm that type_change ...

[Stephen Smalley <sds@tycho.nsa.gov>]

On 07/09/2014 11:10 AM, Daniel J Walsh wrote:
> 
> On 07/08/2014 03:35 PM, Stephen Smalley wrote:
>> On 07/08/2014 03:21 PM, Steve Lawrence wrote:
>>> On 07/07/2014 10:45 AM, Dominick Grift wrote:
>>>> On Mon, 2014-07-07 at 16:24 +0200, Dominick Grift wrote:
>>>>> On Mon, 2014-07-07 at 10:00 -0400, Steve Lawrence wrote:
>>>>>
>>>>>> I can't reproduce the problem with my test policies. The typechange
>>>>>> statements look like they are correctly inserted into the binary and I
>>>>>> am seeing the expected type changes at runtime.
>>>>>>
>>>>>> Is this with your monogam policy?
>>>>>>
>>>>> No, that one is no longer maintained.
>>>>>
>>>>> It is this very small base policy:
>>>>>
>>>>> https://github.com/doverride/e145
>>>>>
>>>> Note though, with that version, that there is no type_change rule from
>>>> devpts_t to device_session_pts_t currently (so if you were to test this
>>>> with sshd then it would be lacking the type change rule)
>>>>
>>>> Either insert that type_change rule manually or test it with the (local)
>>>> login program since there is a type_change session_t
>>>> device_tty_t:chr_file device_session_tty_t rule present.
>>>>
>>>> There is also a conditional type change rule for console_device_t to
>>>> device_session_tty_t.
>>>>
>>>> I cannot imagine me having overlooked anything. Since there are only two
>>>> domains (system_t and session_t), and both are virtually unconfined.
>>>>
>>>>
>>> Ok, finally managed to track down this issue. Turns out to be an
>>> ordering problem. You have your classes listed in alphabetical order.
>>> Order shouldn't matter with CIL and everything should work correctly,
>>> and in most cases is does. However, we assign integer values to each
>>> class based on the order we see them. So the first one we see gets value
>>> 1, second gets 2, etc. If these values don't match up with what
>>> userspace and the kernel expect them to be, things break.
>> Kernel and newer userspace code performs dynamic lookup of class/perm
>> values from strings and handles mapping their own internal indices to
>> the policy-defined values.  So this points to a need to update
>> pam_selinux and other older code to map via string_to_security_class().
> Lets open a bugzilla on this.

Probably need to crawl the fedora source tree and look for any #include
<selinux/flask.h> or #include <selinux/av_permissions.h> references to
identify all packages that need to be updated.  For permission checks,
can just switch over to using selinux_check_access() in most cases and
then all the string lookups are handled for you as well as all of the
ugliness of dealing with the AVC.  May want new wrapper functions for
security_compute_* that take the class as a string and internally call
string_to_security_class() that can be used instead.