[fedora-arm] semanage error Re: Fedora-Xfce-armhfp-21-20140815-sda.raw.xz

[Robert Moskowitz]

On 08/16/2014 05:45 AM, Daniel J Walsh wrote:
> On 08/15/2014 03:34 PM, Robert Moskowitz wrote:
>> My cubieboard2 vanilla see below
>> I move the sshd port, and update SELinux policy with:
>>
>> semanage port -a -t ssh_port_t -p tcp 1234
>>
>> and got the following messages:
>>
>> [ 1828.788735] SELinux:  Permission audit_read in class capability2
>> not defined in policy.
> This means you have a capability defined in policy "audit_read", which
> the kernel does not understand

Well this is a clean install:

# fedora-arm-image-installer/fedora-arm-image-installer.sh 
--image=Fedora-Xfce-armhfp-21-20140815-sda.raw.xz --target=Cubietruck 
--media=/dev/sdb --norootpass

But replacing the Cubietruck uboot with the cubieboard2 uboot:

# dd if=/root/u-boot-sunxi/u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 
seek=8; sync

So I am performing a 'rather common' semanage command to allow sshd to 
listen on a non-standard port, using the provided kernel and stuff.  The 
Cubieboard2 uboot is what is being cleaned up for inclusion in armhfp-21.


>> [ 1828.796870] SELinux: the above unknown classes and permissions will
>> be allowed
>> [ 1829.450779] SELinux:  Context
>> system_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1831.528160] SELinux:  Context
>> system_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1832.890157] SELinux:  Context
>> unconfined_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1834.966398] SELinux:  Context
>> unconfined_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid
>> (unmapped).
> These are types that have been removed from the default packages.  So
> they were defined in the previous policy that you had in the kernel, but
> the new policy you loaded no longer has sandbox_t and vbetool_t. These
> should not be a problem
> unless you had an application running as sanbox_t or vbetool_t, most
> likely not.

Again, I am doing something that lots of others do, that is move sshd to 
another port using a common semanage command.  So I did not do anything 
knowingly wiht sandbox_t or the rest you identify. Something provided in 
the current build is resonding not as it does in F20.

>> But it seems to have worked.  That is SSH can be reached at the
>> changed port.  And yes, I also did the firewall-cmd for the new port
>> number.
>>
>>