When SELinux does a full relabel, it prints a * for each 1000 files that it relabels.

Some users were complaining about a full relabel and not being able to estimate how much time was left. 

I explained to them that I did not know how many files were on the file system, so I could not estimate how much time was left.  They explained to me that there was ways to look at the file system and get then number of inodes, and then you could estimate how much time was left.  I told them patches accepted, and within a couple of days, I got a patch from John Reiser. 

As of policycoreutils-2.1.10-21.fc17

If you do a touch /.autorelabel; reboot or a fixfiles restore

You will see output like


# fixfiles  restore
10%

With the counter slowly rising.

Open source opens the possibility for all of us to contribute and make the whole better.

Thanks John.

Can I install a policy module built on RHEL6 on a RHEL5 box?

First you need to understand policy is compiled statically.  Even if you use interfaces, all the rules are compiled into the policy.pp file.
If you use policy_module(mypol, 1.0), this will generate a gen_require(` ') block for all of the permissions, classes defined in policy. 
Meaning if you compile a policy on RHEL6 and install it on RHEL5 using policy_module(mypol,1.0) you are likely to fail with an error like:

# semodule -i mypol.pp
libsepol.permission_copy_callback: Module mypol depends on permission open in class file, not satisfied
libsemanage.semanage_link_sandbox: Link packages failed semodule:  Failed!

This is the compiler telling you that you tried to install a policy module that required the "open" permission and RHEL5 policy, and kernel for that matter, has no idea what the "open" permission is.

I guess the analogy would be compiling an executable on RHEL6 that uses a function call in a shared library that does not exists on a RHEL5 box, it won't work. 

Usually we recommend that you compile policy on the oldest machines policy that you plan on supporting, then it should be installable on all future versions of that policy.  We don't tend to remove accesses.

Can I install a policy module built on RHEL5 on a RHEL6 box?

Yes you can, but it probably will not work the way you expect!

In RHEL5 the access required to read a file was:

define(`read_file_perms',`{  getattr read ioctl lock }')

In RHEL6 the access required to read a file was:

define(`read_file_perms',`{ open getattr read ioctl lock }')

So if you compile in a line like:

allow httpd_t mysecret_t:file read_file_perms;

On RHEL5 this would allow the apache type to read files labeled mysecret_t, but if you compiled it on RHEL5 and installed it on RHEL6, apache would not be allowed to "open" the file so the access would fail.

Bottom Line:

If you want to ship policy for two MAJOR  DIFFERENT VERSIONS of RHEL then you would need to compile a version for RHEL5 and for RHEL6.

Policy should work for all Minor versions, as long as you compile on the oldest, supported version, although it might work if you compile on a newer version and install on an older version.

Meaning a compiled version of policy on RHEL6.1 should work on RHEL6.2, RHEL6.3 ...

This boolean brings into conflict two of my top goals with SELinux.

1. Make the system secure by default.

The problem with most security systems is NO ONE turns them on.  NO ONE increases the security of their system.
Now while these are exaggerations, I would bet you that 99 % of SELinux users never turn on confined users, or disable the unconfined module .  There are large numbers of people who run SELinux in permissive mode or even disabled.    If we shipped Fedora and RHEL with SELinux disabled, I would bet the number of people who would enable it would be infinitesimally small.    So when I add a feature, I always think about how it would help the vast majority of people.    Will this boolean make my Wife's computer more secure.

2. Keep the unconfined domain unconfined...

Read the blog for why uses expect things to just work, especially from their logged in accounts, especially if they are the admin.

Should deny_ptrace be on by default????

Well deny_ptrace actually confines the unconfined domain, so it conflicts with #2, but if I don't turn it on, for the most part people will not take advantage.  Most users would not see the benefit.  Right now I am going to turn it on by default (Of course I reserve the right to change my mind, or be beaten into submission.)  Any person who wants to disable it permanently can execute.

# setsebool -P deny_ptrace 0

Programmers and system admins if you get a "permission denied" or "Operation not supported" error with ptrace, strace or gdb, it is SELinux causing the problem, and if you need to debug a problem, you can turn the boolean on temporarily.

# setsebool deny_ptrace 0

And do your thing.

Since sysadmins and programmers understand Linux best, it would be easier for them to toggle the security feature.

Now some questions about this feature.

What happened to allow_ptrace boolean in RHEL versions and older Fedora's? 

I originally thought about extending allow_ptrace, but I thought I had better just create a new boolean and remove the old.

allow_ptrace only effected confined users. But since hardly anyone used confined users, I thought I needed a better way to describe the feature, and change its name.  I have removed allow_ptrace and now deny_ptrace will remove all ptrace, sys_ptrace that I know about from the system.

Does deny_ptrace guarantee no domains on my system can ptrace another domain? 

NO
If you load a custom policy with an "allow XYZ self:process ptrace", this boolean will not effect it.  So it only effects actually policy shipped by Fedora or Red Hat.
deny_ptrace does not effect permissive domains,  or permissive mode (obviously),  so if you want to make sure no processes can execute ptrace, you need to disable permissive domains.

After you turn on the deny_ptrace boolean, you can check if any domains are still able to ptrace by executing

# sesearch  -A -C -p ptrace,sys_ptrace | grep -v ^D

What about separation between root and users?

Well SELinux does not know anything about UID users, so root and non root mean nothing to SELinux.  The only way to get this distinction is by setting up confined users and then say run as staff_t as non root and then transition to unconfined_t, or sysadm_t or a confined admin type.  But since hardly anyone uses confined users, this is not an option, if I want to make most computers more secure.

Could you add a bunch of booleans that allows us to turn on and off ptrace per confined domain?

Well this is not really necessary, since most confined domains can not ptrace now, or only could ptrace because of some bugs in the kernel that generated ptrace avc's when running the ps command as root or if a process examined the /proc/PID files of another process.    We have fixed these kernel issues and are removing most domains ability to ptrace permanently, Ie turning deny_ptrace off DOES not allow every domain the ability to ptrace, only a few select domains that we believe might need it.  (Really just user domains.)

The deny_ptrace feature allows an administrator to toggle the ability of processes on the computer system from examining other processes on the system, including user processes.   It can even block processes running as root.

Most people do not realize that any program they run can examine the memory of any other process run by them.  Meaning the computer game you are running on your desktop can watch everything going on in Firefox or a programs like pwsafe or kinit or other program that attempts to hide passwords..

SELinux defines this access as ptrace and sys_ptrace.  These accesses allow one process to read the memory of another process.   ptrace allows developers and administrators to debug how a process is running using tools like strace, ptrace and gdb.    You can even use gdb (GNU Debugger) to manipulate another process running memory and environment. 

The problem is this is allowed by default. 

My wife does not debug programs, why is she allowed to debug them?  As a matter of fact most of the time, I am not debugging applications, so it would be more secure if we could disable it by default.

I created a feature for Fedora 17 called SELinuxDenyPtrace

Here is a youtube video demonstrating the SELinuxDenyPtrace feature.

Check it out.