* Re: [meta-selinux] all files unlabeled_t when using squashfs
2014-11-04 0:48 [meta-selinux] all files unlabeled_t when using squashfs Josh_Pennell
@ 2014-11-05 16:09 ` Joe MacDonald
0 siblings, 0 replies; 2+ messages in thread
From: Joe MacDonald @ 2014-11-05 16:09 UTC (permalink / raw)
To: Josh_Pennell; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]
Hi Josh,
[[yocto] [meta-selinux] all files unlabeled_t when using squashfs] On 14.11.03 (Mon 18:48) Josh_Pennell@Dell.com wrote:
> Hello,
>
>
>
> I’m working on a project using the meta-selinux reference policy on an
> embedded system. The device uses a squashfs file system that is
> labeled during build time. During the build, policy file labels are
> applied using Pseudo and setfiles with an alternate root path
> specified. Also if I modify the build to use sudo setfiles I can
> confirm the file tags are correct.
What about when the system is booted? I mean, can you try relabling the
filesystem on the target itself? Historically it's been a pretty sticky
challenge to get labels correct in a target fs in a cross-build
environment, even when it's only a half-cross scenario (that is,
building on x86-64 for x86-64 but still using the x-build environment).
I've worked on a number of projects in the past where we've had to make
this work and it does tend to be full of blind alleys. :-)
Anyway, it sounds like things are mostly good with your setup, but I'd
like to know if you are able to first do something like booting your
system, verifying you have the unlabeled_t scenario, then do a 'fixfiles
-F restore' or 'fixfiles -F relabel' on your live system, that would
help.
Also, before you boot your system for the first time, can you check to
see if there is a '/.autorelabel' file present and, if so, if there are
any warnings or errors reported during your first boot? Usually if
there is a problem, that'll point toward it.
> Currently this is being done with Yocto 1.3 for prototyping on some older
> hardware but moving forward Yocto 1.7 will be used.
Yeah, if it's at all possible to migrate to something newer, that'd be
your best option. 1.3 is pretty long in the tooth and there's been a
lot of improvements in meta-selinux in the interim.
-J.
>
>
>
> Using a Fedora system it is possible to mount the squashfs file and confirm the
> file labels are correct. When the target system is flashed the file labels for
> the squashfs files are incorrect, but ram disk files are correct. Using ls
> –laZ, all squashfs files are system_u:object_r:unlabeled_t
>
>
>
> The kernel .config values for squsahfs and selinux here here
>
>
>
> CONFIG_SQUASHFS=y
>
> CONFIG_SQUASHFS_XATTR=y
>
> CONFIG_SQUASHFS_ZLIB=y
>
> CONFIG_SQUASHFS_LZO=y
>
> CONFIG_SQUASHFS_XZ=y
>
> # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
>
> CONFIG_SQUASHFS_EMBEDDED=y
>
> CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=10
>
>
>
> CONFIG_SECURITY_SELINUX=y
>
> CONFIG_SECURITY_SELINUX_BOOTPARAM=y
>
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
>
> CONFIG_SECURITY_SELINUX_DISABLE=y
>
> CONFIG_SECURITY_SELINUX_DEVELOP=y
>
> CONFIG_SECURITY_SELINUX_AVC_STATS=y
>
> CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
>
> CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX=n
>
> # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
>
>
>
> Has anyone else run into this problem? Any suggestions on what may be wrong?
>
>
>
> Regards,
>
> josh
>
>
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread