Policy is not managed or store cannot be accessed

[AlannY]

Hi there. I'm new in SELinux world. I'm trying to setup SELinux in Archlinux. Everything seems ok.
Everything successfully built and even runs.

But when I'm trying to do something with SELinux (semanage, semodule), I'm getting to following error:

%# semanage login -l
/usr/sbin/semanage: SELinux policy is not managed or store cannot be accessed.

I don't know what I can do in this situation. I've already asked on Archlinux forum about this problem,
but there are no experts in SELinux, so no one answered.

Sestatus tells me, that SELinux is working:

%# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy

When I'm trying to go to enforcement, the system is hang off. I think, it's normal, because of AVC deniels in log.
I can solve it by creating new module, but I cannot load it, because of 1st error (not managed/not accessed).

I'm
%# id -Z
root:staff_r:insmod_t

What can I do?

I think, that my problem is with version mismatch of selinux tools (checkpolicy,semanage) and refpolicy.
Where can I check it? Currently I have:

kernel26-selinux-2.6.31
selinux-coreutils-7.6
selinux-pam-1.1.0
refpolicy-2.20091117
selinux-sysvinit-2.86
checkpolicy-2.0.20
libselinux-2.0.89
libsemanage-2.0.42
libsepol-2.0.41
selinux-usr-policycoreutils-2.0.77
sepolgen-1.0.18

That everything I have.

Thanks for patience.

[Stephen Smalley]

Post by AlannY
Hi there. I'm new in SELinux world. I'm trying to setup SELinux in Archlinux. Everything seems ok.
Everything successfully built and even runs.
%# semanage login -l
/usr/sbin/semanage: SELinux policy is not managed or store cannot be accessed.
I don't know what I can do in this situation. I've already asked on Archlinux forum about this problem,
but there are no experts in SELinux, so no one answered.
%# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy

Did you build your policy with MONOLITHIC=n in build.conf?
If not, then you need to do that if you want modular/managed policy.

Post by AlannY
When I'm trying to go to enforcement, the system is hang off. I think, it's normal, because of AVC deniels in log.
I can solve it by creating new module, but I cannot load it, because of 1st error (not managed/not accessed).
I'm
%# id -Z
root:staff_r:insmod_t

Hmmm...did you label your filesystems?
What does sestatus -v show?

Post by AlannY
What can I do?
I think, that my problem is with version mismatch of selinux tools (checkpolicy,semanage) and refpolicy.
kernel26-selinux-2.6.31
selinux-coreutils-7.6
selinux-pam-1.1.0
refpolicy-2.20091117
selinux-sysvinit-2.86
checkpolicy-2.0.20
libselinux-2.0.89
libsemanage-2.0.42
libsepol-2.0.41
selinux-usr-policycoreutils-2.0.77
sepolgen-1.0.18
That everything I have.
Thanks for patience.

[AlannY]

Post by Stephen Smalley
Hmmm...did you label your filesystems?
What does sestatus -v show?

SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy

Process contexts:
Current context: root:staff_r:insmod_t
Init context: system_u:system_r:kernel_t
/sbin/agetty system_u:system_r:kernel_t

File contexts:
Controlling term: system_u:object_r:ramfs_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:login_exec_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/sbin/init system_u:object_r:init_exec_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t

[Stephen Smalley]

Post by AlannY

Post by Stephen Smalley
Hmmm...did you label your filesystems?
What does sestatus -v show?

SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy
Current context: root:staff_r:insmod_t
Init context: system_u:system_r:kernel_t

So /sbin/init never transitioned from kernel_t to init_t and thus none
of your processes are in the right security context.

In order for this to happen, one of two things is required:
1) Your /sbin/init program needs the selinux patch to load policy and
then re-exec itself into the right security context, or
2) Your initramfs init script needs to load policy (e.g. chroot
$NEWROOT /usr/sbin/load_policy -i) before running the real init program.

#1 was the original approach in Fedora; #2 is the current approach in
Fedora and Ubuntu.

Post by AlannY
/sbin/agetty system_u:system_r:kernel_t
Controlling term: system_u:object_r:ramfs_t

This is interesting - why is your tty on a ramfs image?

Post by AlannY
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:login_exec_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/sbin/init system_u:object_r:init_exec_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t

[AlannY]

Post by Stephen Smalley
So /sbin/init never transitioned from kernel_t to init_t and thus none
of your processes are in the right security context.
1) Your /sbin/init program needs the selinux patch to load policy and
then re-exec itself into the right security context, or
2) Your initramfs init script needs to load policy (e.g. chroot
$NEWROOT /usr/sbin/load_policy -i) before running the real init program.
#1 was the original approach in Fedora; #2 is the current approach in
Fedora and Ubuntu.

Ok, I'll try to modify initramfs.

Post by Stephen Smalley

Post by AlannY
Controlling term: system_u:object_r:ramfs_t

This is interesting - why is your tty on a ramfs image?

I don't know ;-( It was by default. What can I do to change it?

[Stephen Smalley]

Post by AlannY

Post by Stephen Smalley
So /sbin/init never transitioned from kernel_t to init_t and thus none
of your processes are in the right security context.
1) Your /sbin/init program needs the selinux patch to load policy and
then re-exec itself into the right security context, or
2) Your initramfs init script needs to load policy (e.g. chroot
$NEWROOT /usr/sbin/load_policy -i) before running the real init program.
#1 was the original approach in Fedora; #2 is the current approach in
Fedora and Ubuntu.

Ok, I'll try to modify initramfs.

Post by Stephen Smalley

Post by AlannY
Controlling term: system_u:object_r:ramfs_t

This is interesting - why is your tty on a ramfs image?

I don't know ;-( It was by default. What can I do to change it?

What were you running sestatus from? single-user mode? Normal console
login at runlevel 3? What does "tty" report as your tty device and what
does cat /proc/mounts show?

[Stephen Smalley]

Post by AlannY

Post by Stephen Smalley
So /sbin/init never transitioned from kernel_t to init_t and thus none
of your processes are in the right security context.
1) Your /sbin/init program needs the selinux patch to load policy and
then re-exec itself into the right security context, or
2) Your initramfs init script needs to load policy (e.g. chroot
$NEWROOT /usr/sbin/load_policy -i) before running the real init program.
#1 was the original approach in Fedora; #2 is the current approach in
Fedora and Ubuntu.

Ok, I'll try to modify initramfs.

Since you mentioned that you had a selinux-sysvinit package (and hence
should have had a patched /sbin/init), I looked around and found:
http://aur.archlinux.org/packages/selinux-sysvinit/selinux-sysvinit/sysvinit-init.c.diff

Interestingly, this patch (which is not the same as the one used in the
past by Fedora and Debian) does not try to re-exec init, which is why it
isn't transitioning into its domain.

Further, this patch tries to load policy from /etc/policy.bin. That's a
non-standard location, and won't work unless it happens to be a symlink
to the location used by libsemanage and libselinux
(/etc/selinux/$SELINUXTYPE/policy/policy.NN where SELINUXTYPE is defined
by /etc/selinux/config and NN is the policy format version number).

[AlannY]

Post by Stephen Smalley
Did you build your policy with MONOLITHIC=n in build.conf?
If not, then you need to do that if you want modular/managed policy.

Yes, you are right. I've completely forgot about it.

Thanks. This problem is solved.

[Justin P. Mattock]

Post by AlannY
Hi there. I'm new in SELinux world. I'm trying to setup SELinux in Archlinux. Everything seems ok.
Everything successfully built and even runs.
%# semanage login -l
/usr/sbin/semanage: SELinux policy is not managed or store cannot be accessed.
I don't know what I can do in this situation. I've already asked on Archlinux forum about this problem,
but there are no experts in SELinux, so no one answered.
%# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy
When I'm trying to go to enforcement, the system is hang off. I think, it's normal, because of AVC deniels in log.
I can solve it by creating new module, but I cannot load it, because of 1st error (not managed/not accessed).
I'm
%# id -Z
root:staff_r:insmod_t
What can I do?
I think, that my problem is with version mismatch of selinux tools (checkpolicy,semanage) and refpolicy.
kernel26-selinux-2.6.31
selinux-coreutils-7.6
selinux-pam-1.1.0
refpolicy-2.20091117
selinux-sysvinit-2.86
checkpolicy-2.0.20
libselinux-2.0.89
libsemanage-2.0.42
libsepol-2.0.41
selinux-usr-policycoreutils-2.0.77
sepolgen-1.0.18
That everything I have.
Thanks for patience.

I was getting the same thing until
I did sudo /usr/sbin/semanage *


Justin P. mattock

[AlannY]

Post by Justin P. Mattock
I was getting the same thing until
I did sudo /usr/sbin/semanage *

Not works for me. ;-(

[Justin P. Mattock]

Post by AlannY

Post by Justin P. Mattock
I was getting the same thing until
I did sudo /usr/sbin/semanage *

Not works for me. ;-(

well reading the thread, seems
more than just a simple sudo/su.

my guess is as soon as the policy is loading properly
then semanage should function properly.
(Mr Smalley is the best person to give you info on
this);

Justin P. Mattock