does load_policy default to loading the lowest polvers available?

does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


I had some issue that just confused me (to say the least) It seems that
I have now solved this.

There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
on 29 an one 30. The 29 seemingly had a bug in it.

It seems that load_policy (or its libselinux equivalent) defaults to
the lowest policy available (29 instead of 30 in this case)

Why is that?

I fixed the issue by removing the policy.29 file (i think at least)

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHlnMAAoJENAR6kfG5xmc0IsL+gPvY2hmVUW/77tfYW4ruSJS
F29xdIZiFh/70Nv10T8rWmyY/8YzMELucGMg8117FeFUe0V8YRdBtkOYDwCDrZLh
9uAs3Jrnfa109XxE5PQGAgqIZtfAFTKSpNylDoQPg6kcFWCo1nna3EjgaIC8KuW7
FxpWv/27DtequhIjgwNiW2jhzBhwmfKlCSa1BryRzecoboIz7ApDqdiGQAeNCc8i
I+x6MXZ8P/F2K1aTutJhzjmOUR+7Oy+0il9wtdxGwEbD+GrVLLFBXi5/k9/pNyVX
+hwQTTputG1SJ3JAX3/mFa7OmDvdADxWBXvcw7yWLD6moO3nMcW76QiphbNFu1aF
Vtu037e+TnbQGMqSi2sFllzlGXR9MmWeKcDcF5Nl0P4pVmDbuFcvBcYmlR6VfAqE
fpooQinx130pLHe2vVQqfdPChIlT6wmTX7uPO9/ax16xWrZYjY2bZqaycI5uYCV9
RZIdWUCF+i5JiNKoNjQkJVCI3hdzEoM5aI9iZ3H3MA==
=CMCd
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 09:34 AM, Dominick Grift wrote:
>
> I had some issue that just confused me (to say the least) It seems that
> I have now solved this.
>
> There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
> on 29 an one 30. The 29 seemingly had a bug in it.
>
> It seems that load_policy (or its libselinux equivalent) defaults to
> the lowest policy available (29 instead of 30 in this case)
>
> Why is that?
>
> I fixed the issue by removing the policy.29 file (i think at least)

What policy versions were supported by your kernel (cat 
/sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?

load_policy will try to use the highest policy version that is supported 
by the kernel or by your libsepol.  If supported by the kernel, it can 
just load the file directly.  Otherwise, it can use libsepol to 
downgrade the policy to the highest version supported by the kernel and 
then load the result.  If the version is not supported by either the 
kernel or your libsepol, then it cannot be loaded and it will fall back 
to an older version.

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
> On 10/14/2015 09:34 AM, Dominick Grift wrote:
> >
> >I had some issue that just confused me (to say the least) It seems that
> >I have now solved this.
> >
> >There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
> >on 29 an one 30. The 29 seemingly had a bug in it.
> >
> >It seems that load_policy (or its libselinux equivalent) defaults to
> >the lowest policy available (29 instead of 30 in this case)
> >
> >Why is that?
> >
> >I fixed the issue by removing the policy.29 file (i think at least)
> 
> What policy versions were supported by your kernel (cat
> /sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?

/sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)

That is weird because i have the latest libsepol installed (atleast
pretty recent):

# rpm -qa {libsepol*,libselinux*}
libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
libsepol-2.4-9999.git5aeb4c3.fc24.x86_64

> 
> load_policy will try to use the highest policy version that is supported by
> the kernel or by your libsepol.  If supported by the kernel, it can just
> load the file directly.  Otherwise, it can use libsepol to downgrade the
> policy to the highest version supported by the kernel and then load the
> result.  If the version is not supported by either the kernel or your
> libsepol, then it cannot be loaded and it will fall back to an older
> version.
> 
> 
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHmJyAAoJENAR6kfG5xmc4pYMAJ7Hw4aM4fVblCPTugdRru9m
OGWGS7Qk0i6EhuS49PsDOto/d40eU7nErcMNKCMozsvEpE9W9Jzmt5VsYSBGWz13
OdoQe9zKT2aPaBRWS14zAEJJxhKSdy9jPj81fuhYRyt1qAT+py7btT/0cAczh2Q6
rlUtnsC9b+0pf2Aqr66uBHMkcAUwTZs2qSBs5SATuIyt/E3bFPB82VMZKAyWTlw8
AHrzVWrr/L2yaVAynMW/XNu7swpMqvSh2vHTKXOgaFEzgMqYkKfGHPAhTR6TWET1
9fsiQhWwWmHmiGanFMdy4r3PpNPHlDyekckb8tZK5DKJyJk9tkMh03+7HuIyUSqh
zffsU8+eDXpnxp22Mz24qo1BIHIY8X0WKb8KXCwycBPEIw1x56JQw68+sLroT54z
DUJLAV9E1GQz0VKoMn+ADvOwtP4FUHSD1i0SKTcAIZ/TEAhhY2MdDcVCrbnC6kFA
NoS3AR9sk68IVeyaO2NdQwT8y9MzkfrsrECRG8I4SQ==
=Z/35
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 10:11 AM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
>> On 10/14/2015 09:34 AM, Dominick Grift wrote:
>>>
>>> I had some issue that just confused me (to say the least) It seems that
>>> I have now solved this.
>>>
>>> There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
>>> on 29 an one 30. The 29 seemingly had a bug in it.
>>>
>>> It seems that load_policy (or its libselinux equivalent) defaults to
>>> the lowest policy available (29 instead of 30 in this case)
>>>
>>> Why is that?
>>>
>>> I fixed the issue by removing the policy.29 file (i think at least)
>
>> What policy versions were supported by your kernel (cat
>> /sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
>
> /sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
>
> That is weird because i have the latest libsepol installed (atleast
> pretty recent):
>
> # rpm -qa {libsepol*,libselinux*}
> libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
> libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
> libsepol-2.4-9999.git5aeb4c3.fc24.x86_64

Last release of libsepol predated policy 30 support.

However, if your kernel supports it, it should still be loaded.
The logic is in selinux/libselinux/src/load_policy.c: 
selinux_mkload_policy().  With any modern kernel and configuration, 
libselinux should not need to patch in local definitions or booleans 
(already applied by libsemanage or preserved by the kernel), so maxvers 
should be set to the max of the kernel version 
(/sys/fs/selinux/policyvers) and the libsepol-supported version, and 
that should get loaded.

strace of load_policy might be interesting.

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 10:17:04AM -0400, Stephen Smalley wrote:
> On 10/14/2015 10:11 AM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
> >>On 10/14/2015 09:34 AM, Dominick Grift wrote:
> >>>
> >>>I had some issue that just confused me (to say the least) It seems that
> >>>I have now solved this.
> >>>
> >>>There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
> >>>on 29 an one 30. The 29 seemingly had a bug in it.
> >>>
> >>>It seems that load_policy (or its libselinux equivalent) defaults to
> >>>the lowest policy available (29 instead of 30 in this case)
> >>>
> >>>Why is that?
> >>>
> >>>I fixed the issue by removing the policy.29 file (i think at least)
> >
> >>What policy versions were supported by your kernel (cat
> >>/sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
> >
> >/sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
> >
> >That is weird because i have the latest libsepol installed (atleast
> >pretty recent):
> >
> ># rpm -qa {libsepol*,libselinux*}
> >libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
> >libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
> >libsepol-2.4-9999.git5aeb4c3.fc24.x86_64
> 
> Last release of libsepol predated policy 30 support.
> 
> However, if your kernel supports it, it should still be loaded.
> The logic is in selinux/libselinux/src/load_policy.c:
> selinux_mkload_policy().  With any modern kernel and configuration,
> libselinux should not need to patch in local definitions or booleans
> (already applied by libsemanage or preserved by the kernel), so maxvers
> should be set to the max of the kernel version (/sys/fs/selinux/policyvers)
> and the libsepol-supported version, and that should get loaded.
> 
> strace of load_policy might be interesting.

That is the thing indeed. It works fine if i manually run
load_policy. But when i reboot it seemed to go back to the old one. (I am
not sure how fedora currently loads the policy)

I removed the policy.29 now so i can't easily reproduce it now. and i do
not think an strace of a manual load_policy will reveal much as that
works fine and as expected. The problem only occurred when i rebooted
(when fedora load policy instead of me)

Ohh , hmm maybe its a fedora initramfs issue... they probably have some
old stuff in there

> 
> 
> 
> 
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHmbcAAoJENAR6kfG5xmcH70MAJbBAqr3JkzdJRJsxPZMkr0v
q5VEnlLeKUF4i22YiwY4fkzezpIdF9yfoSrCk/BiWBuFylM+lcTTQxs2RsNHWtM6
X7FPsVdvy+2/PnRNLGqePpMgFzQrBHqoSkY4spRgKpYL6v7psMhCNCTdBGcBHT04
HFx2J6+5dAf2FbDD9NVp2ugMeAU+eJwhvHyWViKyCitc0x8Q9y4ERzVdIrHtBy6J
FJzKY4WRIdBNWjfgQ1a99STArTBIi6M1e+4j3aVqsJ3U52V55mBpGOLZqRs7w3cP
eKMyD+KISP32eIS46pqzJLWpxIp9ALZZVkbANpn+2CYkyghRL3xR+ATBaOwchgdn
RkkfuWRfJhjboH2JSKLKMZ0xKoej9792pAiGVG8H0HnQvSdn6moI++Y/aklBP4al
6tsTI+FcClJwWWykEs+A5rfnzd82T0YyS5UZplZwBnDtlvf5GNLFVd/sCo5q0EZU
6jv9b048kNlGE/9XZJVRQSe/InUa7pdj+p6l72iLDQ==
=2wx1
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 10:29 AM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 10:17:04AM -0400, Stephen Smalley wrote:
>> On 10/14/2015 10:11 AM, Dominick Grift wrote:
>>> On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
>>>> On 10/14/2015 09:34 AM, Dominick Grift wrote:
>>>>>
>>>>> I had some issue that just confused me (to say the least) It seems that
>>>>> I have now solved this.
>>>>>
>>>>> There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
>>>>> on 29 an one 30. The 29 seemingly had a bug in it.
>>>>>
>>>>> It seems that load_policy (or its libselinux equivalent) defaults to
>>>>> the lowest policy available (29 instead of 30 in this case)
>>>>>
>>>>> Why is that?
>>>>>
>>>>> I fixed the issue by removing the policy.29 file (i think at least)
>>>
>>>> What policy versions were supported by your kernel (cat
>>>> /sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
>>>
>>> /sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
>>>
>>> That is weird because i have the latest libsepol installed (atleast
>>> pretty recent):
>>>
>>> # rpm -qa {libsepol*,libselinux*}
>>> libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
>>> libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
>>> libsepol-2.4-9999.git5aeb4c3.fc24.x86_64
>
>> Last release of libsepol predated policy 30 support.
>
>> However, if your kernel supports it, it should still be loaded.
>> The logic is in selinux/libselinux/src/load_policy.c:
>> selinux_mkload_policy().  With any modern kernel and configuration,
>> libselinux should not need to patch in local definitions or booleans
>> (already applied by libsemanage or preserved by the kernel), so maxvers
>> should be set to the max of the kernel version (/sys/fs/selinux/policyvers)
>> and the libsepol-supported version, and that should get loaded.
>
>> strace of load_policy might be interesting.
>
> That is the thing indeed. It works fine if i manually run
> load_policy. But when i reboot it seemed to go back to the old one. (I am
> not sure how fedora currently loads the policy)
>
> I removed the policy.29 now so i can't easily reproduce it now. and i do
> not think an strace of a manual load_policy will reveal much as that
> works fine and as expected. The problem only occurred when i rebooted
> (when fedora load policy instead of me)
>
> Ohh , hmm maybe its a fedora initramfs issue... they probably have some
> old stuff in there

AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka 
load_policy -i).  And the approach to selecting a policy version has 
been stable for quite a while, so I wouldn't expect the libselinux in 
the initramfs to differ in this respect.

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 11:44:00AM -0400, Stephen Smalley wrote:
> On 10/14/2015 10:29 AM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 10:17:04AM -0400, Stephen Smalley wrote:
> >>On 10/14/2015 10:11 AM, Dominick Grift wrote:
> >>>On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
> >>>>On 10/14/2015 09:34 AM, Dominick Grift wrote:
> >>>>>
> >>>>>I had some issue that just confused me (to say the least) It seems that
> >>>>>I have now solved this.
> >>>>>
> >>>>>There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
> >>>>>on 29 an one 30. The 29 seemingly had a bug in it.
> >>>>>
> >>>>>It seems that load_policy (or its libselinux equivalent) defaults to
> >>>>>the lowest policy available (29 instead of 30 in this case)
> >>>>>
> >>>>>Why is that?
> >>>>>
> >>>>>I fixed the issue by removing the policy.29 file (i think at least)
> >>>
> >>>>What policy versions were supported by your kernel (cat
> >>>>/sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
> >>>
> >>>/sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
> >>>
> >>>That is weird because i have the latest libsepol installed (atleast
> >>>pretty recent):
> >>>
> >>># rpm -qa {libsepol*,libselinux*}
> >>>libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
> >>>libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
> >>>libsepol-2.4-9999.git5aeb4c3.fc24.x86_64
> >
> >>Last release of libsepol predated policy 30 support.
> >
> >>However, if your kernel supports it, it should still be loaded.
> >>The logic is in selinux/libselinux/src/load_policy.c:
> >>selinux_mkload_policy().  With any modern kernel and configuration,
> >>libselinux should not need to patch in local definitions or booleans
> >>(already applied by libsemanage or preserved by the kernel), so maxvers
> >>should be set to the max of the kernel version (/sys/fs/selinux/policyvers)
> >>and the libsepol-supported version, and that should get loaded.
> >
> >>strace of load_policy might be interesting.
> >
> >That is the thing indeed. It works fine if i manually run
> >load_policy. But when i reboot it seemed to go back to the old one. (I am
> >not sure how fedora currently loads the policy)
> >
> >I removed the policy.29 now so i can't easily reproduce it now. and i do
> >not think an strace of a manual load_policy will reveal much as that
> >works fine and as expected. The problem only occurred when i rebooted
> >(when fedora load policy instead of me)
> >
> >Ohh , hmm maybe its a fedora initramfs issue... they probably have some
> >old stuff in there
> 
> AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
> load_policy -i).  And the approach to selecting a policy version has been
> stable for quite a while, so I wouldn't expect the libselinux in the
> initramfs to differ in this respect.

Yes, its something else because in permissive mode it seemed to work. So
i suppose what ever it needed to do, it was denied somehow. ofcourse no
AVC denials or any other related messages in the logs. (i suppose
because it happens so early)

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHnlIAAoJENAR6kfG5xmc3MoL/3WsZpohtTkTYDs09t1nl8Us
BSD3NZ+pSTFCb425vH/vBho0VAsLFVMyATnQiKjoJeiBaYiGo88qCy044UokUmOw
2hrp0PFUYPGAwdVaarT8ZVKuOxZ9nA4SdwJT+23KjjEK3Xd26gNlBUf/azhhvmWg
+Z4pAS9sUkmys3VKeqZV+ouEZqeHtusXWVz9p9coyURULODOVm2EPC3NrLt8wvRH
GM8nG4v1yT3oSnVNHACWCiENLeNWJ3GZ0RkhgXobAExKlYHgaNd3qTnVeOtpyffi
GqB4n4JBcNmOrr0i5UCk9GIaEVr5dUW8ddaos+8MY7L4ov4zQLc4QRR8Qt8DO1vk
1++jg2CipNbGPx7og5llMf6bsLXCdR0LcCXvoEy5euUwJNRwKecMo+Jwziig3/JJ
jpWrLLtbORKeP+7GY57q8Sr3jHKm8B8/xNIBQJ6Yu7IKBm/0eGm6egJuFg+Z5cwB
DPDx+JIEs3pp/7VRRDRwDUAqT9xcuFWHlFXSiKl97A==
=38wC
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 11:48 AM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 11:44:00AM -0400, Stephen Smalley wrote:
>> On 10/14/2015 10:29 AM, Dominick Grift wrote:
>>> On Wed, Oct 14, 2015 at 10:17:04AM -0400, Stephen Smalley wrote:
>>>> On 10/14/2015 10:11 AM, Dominick Grift wrote:
>>>>> On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
>>>>>> On 10/14/2015 09:34 AM, Dominick Grift wrote:
>>>>>>>
>>>>>>> I had some issue that just confused me (to say the least) It seems that
>>>>>>> I have now solved this.
>>>>>>>
>>>>>>> There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
>>>>>>> on 29 an one 30. The 29 seemingly had a bug in it.
>>>>>>>
>>>>>>> It seems that load_policy (or its libselinux equivalent) defaults to
>>>>>>> the lowest policy available (29 instead of 30 in this case)
>>>>>>>
>>>>>>> Why is that?
>>>>>>>
>>>>>>> I fixed the issue by removing the policy.29 file (i think at least)
>>>>>
>>>>>> What policy versions were supported by your kernel (cat
>>>>>> /sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
>>>>>
>>>>> /sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
>>>>>
>>>>> That is weird because i have the latest libsepol installed (atleast
>>>>> pretty recent):
>>>>>
>>>>> # rpm -qa {libsepol*,libselinux*}
>>>>> libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
>>>>> libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
>>>>> libsepol-2.4-9999.git5aeb4c3.fc24.x86_64
>>>
>>>> Last release of libsepol predated policy 30 support.
>>>
>>>> However, if your kernel supports it, it should still be loaded.
>>>> The logic is in selinux/libselinux/src/load_policy.c:
>>>> selinux_mkload_policy().  With any modern kernel and configuration,
>>>> libselinux should not need to patch in local definitions or booleans
>>>> (already applied by libsemanage or preserved by the kernel), so maxvers
>>>> should be set to the max of the kernel version (/sys/fs/selinux/policyvers)
>>>> and the libsepol-supported version, and that should get loaded.
>>>
>>>> strace of load_policy might be interesting.
>>>
>>> That is the thing indeed. It works fine if i manually run
>>> load_policy. But when i reboot it seemed to go back to the old one. (I am
>>> not sure how fedora currently loads the policy)
>>>
>>> I removed the policy.29 now so i can't easily reproduce it now. and i do
>>> not think an strace of a manual load_policy will reveal much as that
>>> works fine and as expected. The problem only occurred when i rebooted
>>> (when fedora load policy instead of me)
>>>
>>> Ohh , hmm maybe its a fedora initramfs issue... they probably have some
>>> old stuff in there
>
>> AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
>> load_policy -i).  And the approach to selecting a policy version has been
>> stable for quite a while, so I wouldn't expect the libselinux in the
>> initramfs to differ in this respect.
>
> Yes, its something else because in permissive mode it seemed to work. So
> i suppose what ever it needed to do, it was denied somehow. ofcourse no
> AVC denials or any other related messages in the logs. (i suppose
> because it happens so early)

Prior to initial policy load, everything is allowed (even if enforcing), 
so it can't be a SELinux permission denial.

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 12:05:27PM -0400, Stephen Smalley wrote:
> On 10/14/2015 11:48 AM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 11:44:00AM -0400, Stephen Smalley wrote:
> >>On 10/14/2015 10:29 AM, Dominick Grift wrote:
> >>>On Wed, Oct 14, 2015 at 10:17:04AM -0400, Stephen Smalley wrote:
> >>>>On 10/14/2015 10:11 AM, Dominick Grift wrote:
> >>>>>On Wed, Oct 14, 2015 at 09:56:04AM -0400, Stephen Smalley wrote:
> >>>>>>On 10/14/2015 09:34 AM, Dominick Grift wrote:
> >>>>>>>
> >>>>>>>I had some issue that just confused me (to say the least) It seems that
> >>>>>>>I have now solved this.
> >>>>>>>
> >>>>>>>There were two policy.X files in my /etc/selinux/SELINUXTYPE/policy dir,
> >>>>>>>on 29 an one 30. The 29 seemingly had a bug in it.
> >>>>>>>
> >>>>>>>It seems that load_policy (or its libselinux equivalent) defaults to
> >>>>>>>the lowest policy available (29 instead of 30 in this case)
> >>>>>>>
> >>>>>>>Why is that?
> >>>>>>>
> >>>>>>>I fixed the issue by removing the policy.29 file (i think at least)
> >>>>>
> >>>>>>What policy versions were supported by your kernel (cat
> >>>>>>/sys/fs/selinux/policyvers) and by your libsepol (checkpolicy -V)?
> >>>>>
> >>>>>/sys/fs/selinux/policyvers says: version 30, and checkpolicy says: 29 (compatibility range 29-15)
> >>>>>
> >>>>>That is weird because i have the latest libsepol installed (atleast
> >>>>>pretty recent):
> >>>>>
> >>>>># rpm -qa {libsepol*,libselinux*}
> >>>>>libselinux-utils-2.4-9999.git5aeb4c3.fc24.x86_64
> >>>>>libselinux-2.4-9999.git5aeb4c3.fc24.x86_64
> >>>>>libsepol-2.4-9999.git5aeb4c3.fc24.x86_64
> >>>
> >>>>Last release of libsepol predated policy 30 support.
> >>>
> >>>>However, if your kernel supports it, it should still be loaded.
> >>>>The logic is in selinux/libselinux/src/load_policy.c:
> >>>>selinux_mkload_policy().  With any modern kernel and configuration,
> >>>>libselinux should not need to patch in local definitions or booleans
> >>>>(already applied by libsemanage or preserved by the kernel), so maxvers
> >>>>should be set to the max of the kernel version (/sys/fs/selinux/policyvers)
> >>>>and the libsepol-supported version, and that should get loaded.
> >>>
> >>>>strace of load_policy might be interesting.
> >>>
> >>>That is the thing indeed. It works fine if i manually run
> >>>load_policy. But when i reboot it seemed to go back to the old one. (I am
> >>>not sure how fedora currently loads the policy)
> >>>
> >>>I removed the policy.29 now so i can't easily reproduce it now. and i do
> >>>not think an strace of a manual load_policy will reveal much as that
> >>>works fine and as expected. The problem only occurred when i rebooted
> >>>(when fedora load policy instead of me)
> >>>
> >>>Ohh , hmm maybe its a fedora initramfs issue... they probably have some
> >>>old stuff in there
> >
> >>AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
> >>load_policy -i).  And the approach to selecting a policy version has been
> >>stable for quite a while, so I wouldn't expect the libselinux in the
> >>initramfs to differ in this respect.
> >
> >Yes, its something else because in permissive mode it seemed to work. So
> >i suppose what ever it needed to do, it was denied somehow. ofcourse no
> >AVC denials or any other related messages in the logs. (i suppose
> >because it happens so early)
> 
> Prior to initial policy load, everything is allowed (even if enforcing), so
> it can't be a SELinux permission denial.

I know that , but it seems to work in permissive mode but not in
enforcing mode.., and I think it only happens if there are both 29 and
30 policy files (i use this policy on several systems and the issue only
happened on one the system that had the dangling 29 file)

Anyhow too much speculation. I just do not know what is
going on. However I think I seem to have solved the immediate issue so I
am good with that. I will keep my eyes open for related issues.

It is a very strange issue because it also did not happen
consistently. First I thought it was a policy issue, but I have this
policy on various identical systems and it only happened on one
particular system (the system that had the dangling 29 file it turns
out), then I thought it was hardware specific issue because It worked
fine on all my other systems (same policy just different hardware).

Heck , I may turn out to be wrong, and the issue may happen again after
all since I can't reproduce it very consistently, it happens almost
always (every boot) but not quite.

Thanks for the information. Please consider the issue resolved and if it
happens again or if I find out what caused it then I will let the list
know.

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHoIUAAoJENAR6kfG5xmcSWoL/1aXu3uWykJOZ/vxeuMRXKEE
p1pr1wEU1Q54Zam+OcRfBdgf4ZILbo04NBXUgnpawT0SY54Kv8RkZDzCjRonu5Gb
/82a09WE9VARHfWQIdqEPH1p3a3Ukv1ZgyHkyNi5YwsVoxU0jpNgyoD8P0AOL/MZ
hNZlg/57wjtT80RnpOdplhQAbJSzyolzSto+Muxa1WX7Scy5i84J8penRF4i/yWz
A91MnNksPnQo305W3XresO1NGditFH6eWa1nocGWvlboFprGQm6IhZJmY1bxU+QD
Z2lBJDdKXyzIKb415rHNp6n8ySK/t5PDOFT/1Pvvb+itI2FGd8hS82uPZKR/MP65
ggkFasMMbSQXO/a//zJuCgaYbJifNcexsOrQDjAsSQO7xyCJHnQrFXImI6UtA0Xs
B49w3ELHjfTxqlkcRGXgBmVnr7nZfWnyHtpoSjB+Oz0ZZIl+fU7s43LpWv7O4Ywv
nBVd8RWpuL7wqLef81AsiLo6DqI6riELX2AALA+Qsg==
=Pftr
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 12:05:27PM -0400, Stephen Smalley wrote:
> >
> >>AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
> >>load_policy -i).  And the approach to selecting a policy version has been
> >>stable for quite a while, so I wouldn't expect the libselinux in the
> >>initramfs to differ in this respect.

I just reboot that machine, and it happened again! So the dangling 29
file was not at all related.

This issue is so weird, and so hard to narrow down.

I have about 7 systems all with the same policy, same selinux userspace, different form factors,
2 laptops (one rawhide, on fedora 23), one worksstation (rawhide) and
4 qemu/kvm guests (all rawhide)

Theyre pretty much all identical from a config point of view except that
the workstation is a hypervisor and router

The workstation is the issue. I am getting avc denials for the same
access vectors (but only on the workstation):

system {status start }

(obivously the rules to allow it are present in the policy)

Is it Linux 4.3 related -> then why does it work on my rawhide laptop,
and kvm guests fine
Is it my policy -> then why does it work on all my other systems fine
Is it hardware related -> seems to be the only explanation but then why
does it not happen consistently? (it happens most of the time when boot
but not always)
Maybe it is a combination of hardware + linux 4.3?

So many questions and so hard to debug...

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHoXEAAoJENAR6kfG5xmc5loL/0w5t5R0q5xzTnufiwMmFAmE
O8Gm9TYSrH/J5IWYGJveEfjH5TVQ3ZXpmPFk32iUb/RZec0B4oBgvSIhWz+LzEyu
Sx0ygz12sXrFkswKbPHiOD1l8ewo5W2m/hdO2x3XB+EUfajwg1x/zo6D+UF0uvMC
qL3fWHvRaQqyeE20CE6L3iiPAKPQs1Y9oLbKv1Lkci7DTEsbQVN47eygyRqeD6p4
qN8LrH9MIh82kFyFUMBynNlWwXqeZSA2awA7Spfw7vWcoQTQEc8QgnfOn5jTky1a
TryUthLoPIVMqm/TdrxngHPrSNWerOdiFpP+3btq6tLcqGX+fsePsFSW3Yv3jNcq
gkG0d+66IvDnIRxCud+YBnARmm6E/r+78YdvYkgm6J8BSIpiSYGL0RRK3JN3olAd
ohVFfEaM10WoqlTOef2Rls8E7R8ewAqS5livd+aDzkviyuikgby4yRZ2KC3qxzhp
ACLe6uBU5179/sBy70QTeOuy4emi384/P/U1r6b6PA==
=idQ1
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 12:41 PM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 12:05:27PM -0400, Stephen Smalley wrote:
>>>
>>>> AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
>>>> load_policy -i).  And the approach to selecting a policy version has been
>>>> stable for quite a while, so I wouldn't expect the libselinux in the
>>>> initramfs to differ in this respect.
>
> I just reboot that machine, and it happened again! So the dangling 29
> file was not at all related.
>
> This issue is so weird, and so hard to narrow down.
>
> I have about 7 systems all with the same policy, same selinux userspace, different form factors,
> 2 laptops (one rawhide, on fedora 23), one worksstation (rawhide) and
> 4 qemu/kvm guests (all rawhide)
>
> Theyre pretty much all identical from a config point of view except that
> the workstation is a hypervisor and router
>
> The workstation is the issue. I am getting avc denials for the same
> access vectors (but only on the workstation):
>
> system {status start }
>
> (obivously the rules to allow it are present in the policy)

You say "obviously"; how have you verified?  You could run sesearch on 
the kernel's view of the policy (/sys/fs/selinux/policy), or you could 
run compute_av from libselinux.

If allowed by policy but denied by systemd (since those are systemd 
permissions, not kernel ones, and unfortunately use a kernel class), 
then I've only seen that on a policy reload that alters the class 
definitions.  That issue should be fixed by the patch I posted a while 
back for libselinux, which I believe should now be in rawhide.

>
> Is it Linux 4.3 related -> then why does it work on my rawhide laptop,
> and kvm guests fine
> Is it my policy -> then why does it work on all my other systems fine
> Is it hardware related -> seems to be the only explanation but then why
> does it not happen consistently? (it happens most of the time when boot
> but not always)
> Maybe it is a combination of hardware + linux 4.3?
>
> So many questions and so hard to debug...

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 12:53:06PM -0400, Stephen Smalley wrote:
> On 10/14/2015 12:41 PM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 12:05:27PM -0400, Stephen Smalley wrote:
> >>>
> >>>>AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
> >>>>load_policy -i).  And the approach to selecting a policy version has been
> >>>>stable for quite a while, so I wouldn't expect the libselinux in the
> >>>>initramfs to differ in this respect.
> >
> >I just reboot that machine, and it happened again! So the dangling 29
> >file was not at all related.
> >
> >This issue is so weird, and so hard to narrow down.
> >
> >I have about 7 systems all with the same policy, same selinux userspace, different form factors,
> >2 laptops (one rawhide, on fedora 23), one worksstation (rawhide) and
> >4 qemu/kvm guests (all rawhide)
> >
> >Theyre pretty much all identical from a config point of view except that
> >the workstation is a hypervisor and router
> >
> >The workstation is the issue. I am getting avc denials for the same
> >access vectors (but only on the workstation):
> >
> >system {status start }
> >
> >(obivously the rules to allow it are present in the policy)
> 
> You say "obviously"; how have you verified?  You could run sesearch on the
> kernel's view of the policy (/sys/fs/selinux/policy), or you could run
> compute_av from libselinux.
> 
> If allowed by policy but denied by systemd (since those are systemd
> permissions, not kernel ones, and unfortunately use a kernel class), then
> I've only seen that on a policy reload that alters the class definitions.
> That issue should be fixed by the patch I posted a while back for
> libselinux, which I believe should now be in rawhide.
> 

Yes well setools (3) needs to be updated (only supports up to version 29),
but it does not build without a patch and i was hoping fedora would
update its setools (theres a bugzilla open for that). so far it hasnt
done so, and I haven't done so myself either (was hoping they would do
it instead)

Setools(4) doesnt work with my policy (it can't deal with cil namespaces
seemingly, and returns non-sense)

However I did query the, what should be, same policy on my fedora 23
system and the rules are in there. So that is why i said "obviously"

My libselinux is uptodate to 5aeb4c350b5cba13a68fc11e365bede82ad2cafb
This means that it has your fix for the policy reload issue

Could it be that this fix actually introduced this? I do not believe
that but I am not sure. (at this point I am not sure of anything)

Why does it work sometimes but fail most of the time. why does this only
happen on one system. I am pretty sure i do not have any faulty RAM. Also everything else works fine and the
issue always on applies to the "system { start stop status }" access
vectors. any other ones work fine for example "service { start stop
status }" works fine.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHpITAAoJENAR6kfG5xmcD4IL/16NrcWg7ZNRYR5d2wLr7URM
SROPK2px19UYJi134adC7eFJ7efdyRUeCPmhsvB+08cacI55hdqTBeOr5gi854qD
69RdgMccnwVFmB//hXNXi+utP6msBFKbAIo9TpB5+biLji6iTMNFZKK2GWGGstux
b5v3EcWQTjXj12tRXtgiHqqqZgxunbwJWoAH75eJ+dhgJsDa+bSYk7LDNlnfTp9C
Li79NNrMOsXpdCz9Qaqwwkw9z6FyIhURVibGgvEXeya68rbSlM+hjQYSDT+qWz10
eh9SzAmAcyrJ0/DpwJCTnoSu8JbXI/mQzzE1qEFQROY+9DSpnW/n21t0HJCrAg0H
h2Fvk3mOz8A89IJzVMfSLylHZUh12XgYSM4oJXSdVo/7Wz4hAnusRe7AK2U003uF
oPPck0ESRUysCvKKs90VWnnOo+y/NMM6bgZrJGU2IcqXDU/45Mr5GM81hKEeKeG5
hyQD7PhCeOft4T/Z4JSIxLTHNLCCQ6MwOeg2uvxEqQ==
=AdKN
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:

> Setools(4) doesnt work with my policy (it can't deal with cil namespaces
> seemingly, and returns non-sense)
> 

Besides. did you know that setools (4) does not use
/sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
instead. This sounded to me like a bad idea. Mainly because you don't
know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
is currently actually loaded into the system. 

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHpMaAAoJENAR6kfG5xmcdgkL/i7Az5S0OfmesKBEYshpztyV
UIgQ4gSQDPAe5TkVfjSUzGyaZDIv01RbvCXcl5gWAYpdQuMW97FpAtWwSyz6cRrT
63oKBUJcuCJgIrx5kp6IWBemYVWoNy+/x3VDEOLp5gNbQUhmLRsrfIUK1Ui0DdSo
ya0Up4tLMbxtZQweDuOKiY2PBfSrf/MpmSpEk2um7QXiJbtePOUlVRRt4Cm9vvq3
IJlzalLaYtygp/HNaiYni3cSyDOElDluN3HalGI1U1NYUGzcHfmiyR/6BJVHg1DO
XkhMRzu6Jj1D00KIbjf6VFFp7vhmHR7X+OG8OVUHZqq2g1/9OgOBCUq+Pd48FnLw
/w/LFhNJxDrpDd8pvXJvqNw648IrgbrXiqTkunRkyM7n5l1pLO3DNqNSpOZRA17G
FKiD6vD+C1XAXzBVi6MDrpGyNPO5LJbnoxV3zFQA+Q8v+wlgpmeQUYvDCMx6gqP3
+3GDAEiIosP4VI72QUVbZKcksmVfzrRtTm2nlIQxFA==
=RdNr
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 01:38 PM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
>
>> Setools(4) doesnt work with my policy (it can't deal with cil namespaces
>> seemingly, and returns non-sense)
>
>
> Besides. did you know that setools (4) does not use
> /sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
> instead. This sounded to me like a bad idea. Mainly because you don't
> know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
> is currently actually loaded into the system.

It should use selinux_current_policy_path() to find the policy.

In any event, did you try compute_av from libselinux on the system in 
question?

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 01:40:10PM -0400, Stephen Smalley wrote:
> On 10/14/2015 01:38 PM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
> >
> >>Setools(4) doesnt work with my policy (it can't deal with cil namespaces
> >>seemingly, and returns non-sense)
> >
> >
> >Besides. did you know that setools (4) does not use
> >/sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
> >instead. This sounded to me like a bad idea. Mainly because you don't
> >know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
> >is currently actually loaded into the system.
> 
> It should use selinux_current_policy_path() to find the policy.
> 
> In any event, did you try compute_av from libselinux on the system in
> question?
> 

# compute_av sys.id:sys.role:sd_machined.subj:s0
  sys.id:sys.role:sd.subj:s0 system
  allowed= { status start stop }

So yes, the rules are there (but again that is obvious to me because it
works sometimes but not most of the time) If the rules were absent then
it would fail all the time.



- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHpYUAAoJENAR6kfG5xmcxhAL/18KZYziduq0hsUwo9kf/Vne
puNoyO7kXgD7iKyMP1r4RSRZViacffnTIsdM1l8VreWMEeL5XugPdwQvNAnOyCMX
hQVmEqpWXbCE636lsa7XLqkpskTDhTxJh3Cz74az7hQFmdMG7DMZm6qy1fMlo8hg
cvAThoj79Kda1I7OodcvRRy2QuR0Q8XZZdREsH22hIT2GdiyR3dhVkGovyWIKKew
cccSnj0G6uXUEQFm/d82zBlPCwz38jvpxse8FLrCFIyfS4VMK/PUO9207K/xfUjB
IVjlVsfUGgFpz8yKTrU7cHhuKn6FafcLZJH/lOwXRTMIfjwYae/goBLfBQyrCjma
yzqeH07xqXMke+9roU1lKSrjCiG1CTbeK5xCzykllP866qHOE8Xj399SpJqr7vb2
LBNSE+AoLXKoVXBMsByBexOK8+iyHwWaKptU6ScemN38U0Mu1tpjHwOe5McMnFez
h+m2KKF3Z8S12OlSHFO1dpeUUqPJeElZrpvJyA+G1w==
=qwgA
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 01:40:10PM -0400, Stephen Smalley wrote:
> On 10/14/2015 01:38 PM, Dominick Grift wrote:
> >On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
> >
> >>Setools(4) doesnt work with my policy (it can't deal with cil namespaces
> >>seemingly, and returns non-sense)
> >
> >
> >Besides. did you know that setools (4) does not use
> >/sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
> >instead. This sounded to me like a bad idea. Mainly because you don't
> >know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
> >is currently actually loaded into the system.
> 
> It should use selinux_current_policy_path() to find the policy.
> 
> In any event, did you try compute_av from libselinux on the system in
> question?
> 

Demo, proof (only 8 minutes long):

https://www.youtube.com/watch?v=iNOxp2d_ws0

I demonstrates the inconsistency, also it proves that the rules are
loaded

> 
> 
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHpnrAAoJENAR6kfG5xmcpkUL/jLi74ktX9Fy9uzs1pG3DtKi
67+455YxFjjpLvoZxezeGHQkMKRs16uOv1yb9J4zWzQ+veDUOasfmylmKlJxE8Zx
oO7OcwAYv778Nr7PMPx90IFlYCz2plmk3S1rlx2HsoUyhxQbLh4xPV3apZtjlyle
TpzNsL1muqukjplISSc6d46OkTbtmNirWFBKzZYL6mE+XGJrU/DaZMVqguQPVedP
WWgE/R5nhr+0fqmT6chsZA7DCHfuy24fdRyMDu1pqip2RyfO1VR+5mWG/4MOSZn4
cXCZ/rbV9peSNsUgDUtKgnNWlUUYD6WQEVpuqh0pMrP577KgFSXnwGlcsCziubeK
2WPzSqTY+1j8rKiiWkIgtUi01S2CgpJvQ4EkDq4jZYr332Gk7gRQFQx1RLUukbdN
EZYxtVn92nR+lhtdgChATKRIHM9LG61FZO1iXyjpKje1edH3CgBDgHAGVv3UoObe
1Ruo3Mr1N3aSH6Wph64VEZReIneISKVMU8a1LTY23g==
=TKEp
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Stephen Smalley]

On 10/14/2015 01:34 PM, Dominick Grift wrote:
> On Wed, Oct 14, 2015 at 12:53:06PM -0400, Stephen Smalley wrote:
>> On 10/14/2015 12:41 PM, Dominick Grift wrote:
>>> On Wed, Oct 14, 2015 at 12:05:27PM -0400, Stephen Smalley wrote:
>>>>>
>>>>>> AFAIK, systemd just calls selinux_init_load_policy() in libselinux (aka
>>>>>> load_policy -i).  And the approach to selecting a policy version has been
>>>>>> stable for quite a while, so I wouldn't expect the libselinux in the
>>>>>> initramfs to differ in this respect.
>>>
>>> I just reboot that machine, and it happened again! So the dangling 29
>>> file was not at all related.
>>>
>>> This issue is so weird, and so hard to narrow down.
>>>
>>> I have about 7 systems all with the same policy, same selinux userspace, different form factors,
>>> 2 laptops (one rawhide, on fedora 23), one worksstation (rawhide) and
>>> 4 qemu/kvm guests (all rawhide)
>>>
>>> Theyre pretty much all identical from a config point of view except that
>>> the workstation is a hypervisor and router
>>>
>>> The workstation is the issue. I am getting avc denials for the same
>>> access vectors (but only on the workstation):
>>>
>>> system {status start }
>>>
>>> (obivously the rules to allow it are present in the policy)
>
>> You say "obviously"; how have you verified?  You could run sesearch on the
>> kernel's view of the policy (/sys/fs/selinux/policy), or you could run
>> compute_av from libselinux.
>
>> If allowed by policy but denied by systemd (since those are systemd
>> permissions, not kernel ones, and unfortunately use a kernel class), then
>> I've only seen that on a policy reload that alters the class definitions.
>> That issue should be fixed by the patch I posted a while back for
>> libselinux, which I believe should now be in rawhide.
>
>
> Yes well setools (3) needs to be updated (only supports up to version 29),
> but it does not build without a patch and i was hoping fedora would
> update its setools (theres a bugzilla open for that). so far it hasnt
> done so, and I haven't done so myself either (was hoping they would do
> it instead)
>
> Setools(4) doesnt work with my policy (it can't deal with cil namespaces
> seemingly, and returns non-sense)
>
> However I did query the, what should be, same policy on my fedora 23
> system and the rules are in there. So that is why i said "obviously"
>
> My libselinux is uptodate to 5aeb4c350b5cba13a68fc11e365bede82ad2cafb
> This means that it has your fix for the policy reload issue
>
> Could it be that this fix actually introduced this? I do not believe
> that but I am not sure. (at this point I am not sure of anything)

I don't see why, but you can certainly test that easily enough - just 
revert that change and rebuild your libselinux, see if you continue to 
get the denials on that system.  If not, then re-apply that change, 
rebuild your libselinux, and confirm that you once again get denials on 
that system.

You could also add some instrumentation to selinux_check_access() and 
avc_has_perm() to try to discover more about why it is failing.  You can 
just add further avc_log() calls and they should go to the audit and 
journal logs.  You could log the class -> sclass and perm -> av mappings 
obtained by selinux_check_access() prior to calling avc_has_perm().

> Why does it work sometimes but fail most of the time. why does this only
> happen on one system. I am pretty sure i do not have any faulty RAM. Also everything else works fine and the
> issue always on applies to the "system { start stop status }" access
> vectors. any other ones work fine for example "service { start stop
> status }" works fine.

Re: does load_policy default to loading the lowest polvers available?

[Christopher J. PeBenito]

On 10/14/2015 1:40 PM, Stephen Smalley wrote:
> On 10/14/2015 01:38 PM, Dominick Grift wrote:
>> On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
>>
>>> Setools(4) doesnt work with my policy (it can't deal with cil namespaces
>>> seemingly, and returns non-sense)

Dominick, would you mind sending me your policy off-list so I can debug
this?

>> Besides. did you know that setools (4) does not use
>> /sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
>> instead. This sounded to me like a bad idea. Mainly because you don't
>> know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
>> is currently actually loaded into the system.
> 
> It should use selinux_current_policy_path() to find the policy.

It does use it, but as a fallback. I've since changed the code to try
the selinux_current_policy_path() first.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Oct 14, 2015 at 04:30:34PM -0400, Christopher J. PeBenito wrote:
> On 10/14/2015 1:40 PM, Stephen Smalley wrote:
> > On 10/14/2015 01:38 PM, Dominick Grift wrote:
> >> On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
> >>
> >>> Setools(4) doesnt work with my policy (it can't deal with cil namespaces
> >>> seemingly, and returns non-sense)
> 
> Dominick, would you mind sending me your policy off-list so I can debug
> this?

its public:

https://github.com/DefenSec/dssp

how to use it:

https://github.com/defensec/dssp/wiki

> 
> >> Besides. did you know that setools (4) does not use
> >> /sys/fs/selinux/policy? It uses /etc/selinux/SELINUXTYPE/policy/policy.X
> >> instead. This sounded to me like a bad idea. Mainly because you don't
> >> know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy that
> >> is currently actually loaded into the system.
> > 
> > It should use selinux_current_policy_path() to find the policy.
> 
> It does use it, but as a fallback. I've since changed the code to try
> the selinux_current_policy_path() first.
> 
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWHrxFAAoJENAR6kfG5xmcwJUMAIo7kMjstv+yIupVzl2ZW+bK
AxuSEmmr9R2hF8hGb5pxdoFlimnwosUHFb00I31vrkQNZ1gaC8s7OG/FzELzFrfi
bCt5Ub5lhl0QWY38YStF3UWaP1DyqL90SNezDWS5fY+grEbjadxyGe8fuBzYOz57
KRWO5HpoGqN7i5O7OZ2VaqiU4t4MehYkCUj//dYdMbiVvDvgo2wFVMf9CYCZ5UTb
PxOE3TyX/rbLHXEFIVBdEEWw9AhS+zIYSFS1nVfh69xzoefLTUZ0cbcYaixhBBKA
deRK1pN6jauAXz1KUimhqo7/qGzD5MYKtvG0wCmBGaoibOVW8dNE0aQRkZ5xPsQZ
Y5fa4IklzIAzw2pLhuHdhgJsL96AqyU3fykmM+07k5mD5kQgD737XFAzQ4VUa7tI
ixaoK8/Gh8oTl4tGEL0DuSQBr9y2biP5/Z3RKrSzoJZIW5JavBozoYgXJTFXKiGQ
UcabVk6VoHlLre3wgK/M3SitytrqMZKN4nbQv4w7xg==
=qa39
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Richard Haines]

I'm not sure if this will resolve the problem but you say it only happens
on the workstation build. I assume then you may be loading X windows, therefore
try setting up a /etc/X11/xorg.conf.d file with the following:

Section "Module"
        SubSection "extmod"
                Option "SELinux mode disabled"
        EndSubSection
EndSection

If this works then the problems are:
1) Your policy does not have an x_contexts file (I didn't see one in your CIL policy)
2) The X windows object manager probably still looks for the xserver_object_manager
boolean to enable/disable X. If you add this to your policy and default to false
you will not need the above entry in xorg.conf.d.




> On Wednesday, 14 October 2015, 21:36, Dominick Grift <dac.override@gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On Wed, Oct 14, 2015 at 04:30:34PM -0400, Christopher J. PeBenito wrote:
>>  On 10/14/2015 1:40 PM, Stephen Smalley wrote:
>>  > On 10/14/2015 01:38 PM, Dominick Grift wrote:
>>  >> On Wed, Oct 14, 2015 at 07:34:16PM +0200, Dominick Grift wrote:
>>  >>
>>  >>> Setools(4) doesnt work with my policy (it can't deal with 
> cil namespaces
>>  >>> seemingly, and returns non-sense)
>> 
>>  Dominick, would you mind sending me your policy off-list so I can debug
>>  this?
> 
> its public:
> 
> https://github.com/DefenSec/dssp
> 
> how to use it:
> 
> https://github.com/defensec/dssp/wiki
> 
>> 
>>  >> Besides. did you know that setools (4) does not use
>>  >> /sys/fs/selinux/policy? It uses 
> /etc/selinux/SELINUXTYPE/policy/policy.X
>>  >> instead. This sounded to me like a bad idea. Mainly because you 
> don't
>>  >> know if the /etc/selinux/SELINUXTYPE/policy/policy.X is the policy 
> that
>>  >> is currently actually loaded into the system.
>>  > 
>>  > It should use selinux_current_policy_path() to find the policy.
>> 
>>  It does use it, but as a fallback. I've since changed the code to try
>>  the selinux_current_policy_path() first.
>> 
>> 
>>  -- 
>>  Chris PeBenito
>>  Tresys Technology, LLC
>>  www.tresys.com | oss.tresys.com
>>  _______________________________________________
>>  Selinux mailing list
>>  Selinux@tycho.nsa.gov
>>  To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>  To get help, send an email containing "help" to 
> Selinux-request@tycho.nsa.gov.
> 
> - -- 
> 02DFF788
> 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQGcBAEBCgAGBQJWHrxFAAoJENAR6kfG5xmcwJUMAIo7kMjstv+yIupVzl2ZW+bK
> AxuSEmmr9R2hF8hGb5pxdoFlimnwosUHFb00I31vrkQNZ1gaC8s7OG/FzELzFrfi
> bCt5Ub5lhl0QWY38YStF3UWaP1DyqL90SNezDWS5fY+grEbjadxyGe8fuBzYOz57
> KRWO5HpoGqN7i5O7OZ2VaqiU4t4MehYkCUj//dYdMbiVvDvgo2wFVMf9CYCZ5UTb
> PxOE3TyX/rbLHXEFIVBdEEWw9AhS+zIYSFS1nVfh69xzoefLTUZ0cbcYaixhBBKA
> deRK1pN6jauAXz1KUimhqo7/qGzD5MYKtvG0wCmBGaoibOVW8dNE0aQRkZ5xPsQZ
> Y5fa4IklzIAzw2pLhuHdhgJsL96AqyU3fykmM+07k5mD5kQgD737XFAzQ4VUa7tI
> ixaoK8/Gh8oTl4tGEL0DuSQBr9y2biP5/Z3RKrSzoJZIW5JavBozoYgXJTFXKiGQ
> UcabVk6VoHlLre3wgK/M3SitytrqMZKN4nbQv4w7xg==
> =qa39
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to 
> Selinux-request@tycho.nsa.gov.
> 

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Oct 15, 2015 at 11:58:16AM +0000, Richard Haines wrote:
> I'm not sure if this will resolve the problem but you say it only happens
> on the workstation build. I assume then you may be loading X windows, therefore
> try setting up a /etc/X11/xorg.conf.d file with the following:
> 
> Section "Module"
>         SubSection "extmod"
>                 Option "SELinux mode disabled"
>         EndSubSection
> EndSection
> 
> If this works then the problems are:
> 1) Your policy does not have an x_contexts file (I didn't see one in your CIL policy)
> 2) The X windows object manager probably still looks for the xserver_object_manager
> boolean to enable/disable X. If you add this to your policy and default to false
> you will not need the above entry in xorg.conf.d.
> 

Thanks for the suggestion, I already have that snippet, so this is not
the issue. It would not make sense either because without the above
things would consistently fail.

This issue I have is inconsistent. One boot everything is fine , and the next
the issue can happen.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWH5csAAoJENAR6kfG5xmcWh4L/0tZXzsAzk28D8blZeX+lp7O
EraCItPr/chIIJ2Cq4nUtCOgYq5ebGR4InZZufsaT9JvOW+GqV3ktGydnfo9+odN
wPcU+/jNW2vYNzVoTBy35E6bUSBWTzDSEUlyhJysQZEzmodf4VmiSRaLEUhaQxci
EwDet5RQEQ3xBq9LXgw2YHKUkbiPGA35Rkz1atwLBVVJuHnbSeSAWwTx3AbQaKrF
zK1OkqmwdPWgQ5b2Jq6nVgWjbCkjiaNvmTZjLCKJRx6tPWlAucsI9SVihO4vUL7n
lKh2dK/Vci7GRtfP23VEh9p97phxNborXcvrGA6JQWOV0aAgL8pbg2t4ecMJw9qt
RZSsyehWW1I1M7SKcFj5vRAwE/UDycK0uriHrgx2vvVhx8rtHE2HU/DFxKWDhi9Y
bTE1olMTQH0cUZoePvymbsKVS6XKLKYPgL5lgiCu8mgTAdPJMZQGvrgg1l3H1Xv7
G740LSaRbCMr+Mh2GV+auBK8ykjq3nrbWSJquQD+gQ==
=NW+R
-----END PGP SIGNATURE-----

Re: does load_policy default to loading the lowest polvers available?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I *think* i have this issue figured out now. It seems that it was
mcstransd. Now that I have disabled it, the issue seems to be gone (only
tested a couple of boots but i am hopefull)

When I did a firmware upgrade, requiring phyiscal access I noticed that
/bin/login requested mac_admin, and that it wanted to set the context of
tty1 with the translated security level (SystemLow), but that somehow
this didn't work and so it was unable the relabel the tty.

Obviously that is not directly related to the systemd issue since by
then systemd would already have failed. It did however prompted me to
think about the possibility of mcstransd's presence being related (since
only that system has mcstransd enabled, and this issue is only on this
system)

So i decided to just have a look and see what happens, and things
started working. Booted a couple of times without mcstransd enabled and
all if well so far.

So mcstransd causes problems, and i have disabled it

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWVzicAAoJENAR6kfG5xmc72QL/iR20UjuQfzDNSzLt21J2ypQ
SSJDf/3VB9qDnBJ/r+O3UBp3uCDl/UUHpi7hNziw6A875LE/3vB8Ohjg/YmQnVVP
lQo/LpFFAx78WeyUxjja956TimXwlDyEKaCwwh0zgTXt6rIEa3eKqtNN+qOt5mib
L/TmSdbVJmqn/ZyB57noENLMJcBplR2C8cJRiWmPvr8FVb3tEW+VXHZuQSjHWOWR
PT5JwLpRhjSLfBUvMdWD+pRpuUvqzZ1s2l82sP3vl66iq33jAUI/R6P13kC6yOnH
E1PJeyKd0IhH42UpmKGSelYL0dcyPEDWTA7a/yBBgeDyPhJfdHvYbB7bz5aS0qvw
BSohVOvF4fJ2gfIfckX30NY1JuN4LHTSGDGrMOT/UdXvS6J/JM38zeWh3UIkWgdN
VM5SDbj0/UV01LaPMDgPo0qZl2nEDtzXfjj33bDZsn5J+t/V4SZ/OQ5k3Ca5m0nN
9g6ysP7sy0K66fB3kbzRksxiyo6e6zbDbEwvyDVgrw==
=N1O+
-----END PGP SIGNATURE-----