semanage error Re: Fedora-Xfce-armhfp-21-20140815-sda.raw.xz

Sunday, 17 August 2014

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.
>
> 

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007