Was this a low memory system?

What is a low memory system?

512 MB or less

512 mb should be plenty for a VM.

Was this during an install or an update?

Update.

I have no idea.


Does yum reinstall selinux-policy-targeted

Reproduce the error?

768mb appears to be enough for now.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Hello,
I have the same problem in F19:
# setsebool -P httpd_read_user_content 1
SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory
/sbin/load_policy: Can't load policy: Cannot allocate memory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory
/sbin/load_policy: Can't load policy: Cannot allocate memory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
Could not change policy booleans 

What can I do with them?

uname -a
Linux ... 3.9.9-301.fc19.i686.PAE #1 SMP Thu Jul 4 15:25:09 UTC 2013 i686 i686 i386 GNU/Linux

# LC_ALL=C yum reinstall selinux-policy-targeted
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package selinux-policy-targeted.noarch 0:3.12.1-59.fc19 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
 Package                                       Arch                         Version                               Repository                     Size
======================================================================================================================================================
Reinstalling:
 selinux-policy-targeted                       noarch                       3.12.1-59.fc19                        updates                       4.0 M

Transaction Summary
======================================================================================================================================================
Reinstall  1 Package

Total download size: 4.0 M
Installed size: 18 M
Is this ok [y/d/N]: y
Downloading packages:
selinux-policy-targeted-3.12.1-59.fc19.noarch.rpm                                                                              | 4.0 MB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : selinux-policy-targeted-3.12.1-59.fc19.noarch                                                                                      1/1 
SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.29:  Cannot allocate memory
load_policy:  Can't load policy:  Cannot allocate memory
  Verifying  : selinux-policy-targeted-3.12.1-59.fc19.noarch                                                                                      1/1 

Installed:
  selinux-policy-targeted.noarch 0:3.12.1-59.fc19                                                                                                     

Complete!
#

Than you for your information
JJ

How much memory does your machine have?

$ free
             total       used       free     shared    buffers     cached
Mem:       4133340    1254584    2878756          0      71972     598536
-/+ buffers/cache:     584076    3549264
Swap:      5713916          0    5713916

# uname -a
Linux ... 3.9.9-302.fc19.i686.PAE #1 SMP Sat Jul 6 13:52:23 UTC 2013 i686 i686 i386 GNU/Linux

# setsebool -P httpd_read_user_content 1
SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.29:  Cannot allocate memory
/sbin/load_policy:  Can't load policy:  Cannot allocate memory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.29:  Cannot allocate memory
/sbin/load_policy:  Can't load policy:  Cannot allocate memory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
Could not change policy booleans

Anything in dmesg?

$ ls -sh /etc/selinux/targeted/policy/policy.29
6.3M /etc/selinux/targeted/policy/policy.29

That's just too big.  You need to stop shipping all policy modules and/or tailor what modules get installed to what software is installed on the system so that policy size tracks install size.  rpm does have better support for policy these days...

That is weird, I get

 ls -sh /etc/selinux/targeted/policy/policy.29 
3.2M /etc/selinux/targeted/policy/policy.29

 seinfo 

Statistics for policy file: /sys/fs/selinux/policy
Policy Version & Type: v.28 (binary, mls)

   Classes:            83    Permissions:       253
   Sensitivities:       1    Categories:       1024
   Types:            4176    Attributes:        346
   Users:               9    Roles:              15
   Booleans:          257    Cond. Expr.:       308
   Allow:           84352    Neverallow:          0
   Auditallow:         12    Dontaudit:        7468
   Type_trans:      13513    Type_change:        80
   Type_member:        35    Role allow:         34
   Role_trans:        708    Range_trans:      4690
   Constraints:        97    Validatetrans:       0
   Initial SIDs:       27    Fs_use:             25
   Genfscon:           91    Portcon:           510
   Netifcon:            0    Nodecon:             0
   Permissives:         4    Polcap:              2

Of course I am on F20.

I am on F19.

$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-63.fc19.noarch
$ ls -sh /etc/selinux/targeted/policy/policy.29 
6.3M /etc/selinux/targeted/policy/policy.29

Might be sandbox policy that is installed but not disabled.

# semodule -d sandbox

# semodule -l | grep sandbox
sandbox	1.0.0	Disabled
sandboxX	1.0.0	

This should be fixed in the latest update of policy.

Yes, in dmesg I found problem:

out of vmalloc space - use vmalloc=<size> to increase size ...

Then I added vmalloc=256M (default is 128m) to the end kernel cmd line ...
( vi /etc/default/grub ; grub2-mkconfig -o /boot/grub2/grub.cfg )

reboot

and the command:
# setsebool -P httpd_read_user_content 1
is not problem now ...

Thanks for your inspiration ... 

cat /proc/meminfo
MemTotal:        4133340 kB
MemFree:         2873828 kB
Buffers:           75064 kB
Cached:           534480 kB
SwapCached:            0 kB
Active:           617476 kB
Inactive:         504876 kB
Active(anon):     513780 kB
Inactive(anon):    20968 kB
Active(file):     103696 kB
Inactive(file):   483908 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       3425160 kB
HighFree:        2348220 kB
LowTotal:         708180 kB
LowFree:          525608 kB
SwapTotal:       5713916 kB
SwapFree:        5713916 kB
Dirty:                68 kB
Writeback:             0 kB
AnonPages:        512840 kB
Mapped:           176428 kB
Shmem:             21956 kB
Slab:              65332 kB
SReclaimable:      34228 kB
SUnreclaim:        31104 kB
KernelStack:        2880 kB
PageTables:        12956 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     7780584 kB
Committed_AS:    3112400 kB
VmallocTotal:     262144 kB
VmallocUsed:      112896 kB
VmallocChunk:     127728 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10232 kB
DirectMap2M:      757760 kB

(In reply to Daniel Walsh from comment #20)
> Might be sandbox policy that is installed but not disabled.
> 
> # semodule -d sandbox
> 
> # semodule -l | grep sandbox
> sandbox	1.0.0	Disabled
> sandboxX	1.0.0	
> 
> This should be fixed in the latest update of policy.

I am trying to figure out what is wrong. I have on my F19


# semodule -l | grep sandbox
sandbox	1.0.0	Disabled
sandboxX	1.0.0	

# ls -sh /etc/selinux/targeted/policy/policy.29 
6.3M /etc/selinux/targeted/policy/policy.29

# seinfo
Statistics for policy file: /sys/fs/selinux/policy
Policy Version & Type: v.28 (binary, mls)

   Classes:            83    Permissions:       253
   Sensitivities:       1    Categories:       1024
   Types:            4155    Attributes:        345
   Users:               8    Roles:              14
   Booleans:          254    Cond. Expr.:       303
   Allow:           85979    Neverallow:          0
   Auditallow:        132    Dontaudit:        7225
   Type_trans:      14626    Type_change:        74
   Type_member:        33    Role allow:         33
   Role_trans:        703    Range_trans:      4664
   Constraints:        97    Validatetrans:       0
   Initial SIDs:       27    Fs_use:             25
   Genfscon:           91    Portcon:           514
   Netifcon:            0    Nodecon:             0
   Permissives:         0    Polcap:              2

Eric any ideas why these are different?

semodule -d unconfined

The explosion in size is caused by the file name transition rules.

We need to get these to work with attributes.

# semodule -d unconfined
 sesearch -T | wc
  53479  360698 4053309
# semodule -e unconfined
# sesearch -T | wc
 173079 1196592 13388904

Why so many file name transition rules?  Only should be required for a security-unaware application that creates two or more files in the same directory that should have different security contexts.  If security-aware, it can specify the security context via setfscreatecon() itself.  If files should have same security context, no need for name-based rules.  If different directories, can use regular transition rules.

Also, someone recently pointed out that filename trans rules aren't supported in optional blocks.  Don't know if that matters.

We don't support attributes for any transition rules presently, not just filename ones.

(In reply to Daniel Walsh from comment #25)
> # semodule -d unconfined
>  sesearch -T | wc
>   53479  360698 4053309
> # semodule -e unconfined
> # sesearch -T | wc
>  173079 1196592 13388904

Yes, you are right. I see the same.

We have unconfined domains creating any content causes a transition.  Most of the rules are around /dev, /etc and ~/

This is why we see a huge drop in size when we disable unconfined.pp.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Any update on what is going on here?

I'm going to go ahead an close this bug.  This is not a kernel bug and hopefully the work Dan did to shrink policy has addressed the issue.