I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM

I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 4520 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doing this I believe I found a bug in bug in SELinux,  that I am not
sure how we fix.

Steps to produce bug.

Build and install

http://people.fedoraproject.org/~dwalsh/SELinux/example-1.0-0.fc9.src.rpm

This will install a daemon program

/usr/sbin/example
/var/spool/example
/etc/init.d/example

All of these should be labeled correctly

Now start the daemon
# rpm -Uhv example-1.0-0.fc9.noarch.rpm
# service example start

This will only create a pid file /var/run/example.pid

Now make sure everything is labeled correctly

# ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
/var/run/example.pid
- -rwxr-xr-x  root root system_u:object_r:example_script_exec_t
/etc/init.d/example
- -rwxr-xr-x  root root system_u:object_r:example_exec_t /usr/sbin/example
- -rw-r--r--  root root system_u:object_r:example_var_run_t
/var/run/example.pid
drwxr-xr-x  root root system_u:object_r:example_spool_t /var/spool/example/

Touch a file in /var/spool/example to make sure rpm does not remove with
the package

# touch /var/spool/example/example.tmp

Now I am going to test the uninstall of the package.


rpm -e example

ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
/var/run/example.pid
ls: cannot access /usr/sbin/example: No such file or directory
ls: cannot access /etc/init.d/example: No such file or directory
- -rw-r--r--  root root system_u:object_r:unlabeled_t
/var/run/example.pid
drwxr-xr-x  root root system_u:object_r:var_spool_t    /var/spool/example/

# restorecon -R -v /var/run/example.pid
# ls -lZ /var/run/example.pid
- -rw-r--r--  root root system_u:object_r:unlabeled_t
/var/run/example.pid

It leaves the pid file as unlabeled_t, this is because

/var/run/.*\.*pid	<<none>>

Which tells restorecon to not change any context on a pid file.  But
leaving the file as unlabeled_t causes other problems.

Now I reinstall the package

# rpm -Uhv
/home/devel/dwalsh/sources/RPMS/noarch/example-1.0-0.fc9.noarch.rpm
Preparing...                ###########################################
[100%]
   1:example                ###########################################
[100%]
/sbin/restorecon set context
/var/run/example.pid->system_u:object_r:example_var_run_t:s0
failed:'Permission denied'

AVC is generated

time->Thu Dec 20 19:28:50 2007
type=PATH msg=audit(1198196930.130:1540): item=0
name="/var/run/example.pid" inode=3178877 dev=fd:00 mode=0100644 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:example_var_run_t:s0
type=CWD msg=audit(1198196930.130:1540):  cwd="/"
type=SYSCALL msg=audit(1198196930.130:1540): arch=40000003 syscall=227
success=no exit=-13 a0=bfcbd7e0 a1=1417c1 a2=ba1ed1e0 a3=27 items=1
ppid=23898 pid=23928 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts2 comm="restorecon" exe="/sbin/setfiles"
subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
 pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
tcontext=system_u:object_r:example_var_run_t:s0 tclass=file

If I pipe this to audit2why
type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
 pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
	Was caused by:
		Unknown - would be allowed by active policy
		Possible mismatch between this policy and the one under which the
audit message was generated.
		Possible mismatch between current in-memory boolean settings vs.
permanent ones.


If I run restorecon on it now, it is fine.

If I do the exact same steps above, but change the context on
/var/run/example.pid to say bin_t.

The install happens successfully.

It seems that during the rpm update the policy in the kernel is
different then when it completes.  All the postinstall is doing is

# semodule -s targeted -i example.pp
followed by a fixfiles on the files in example.spec

Why this would work outside the rpm transaction but not inside is the
bug.  Why does it work with the label of bin_t, but not when it is
labeled unlabeled_t?







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHa9MhrlYvE4MpobMRAi2JAKCG3CwfOhRYvda7VrL3ehNx6DC5mQCfRtuD
QFGHQmAek1Pt91e4vorEY9w=
=igaV
-----END PGP SIGNATURE-----

[-- Attachment #2: example.spec --]
[-- Type: text/plain, Size: 1822 bytes --]

Summary: Example policy application
Name: example
Version: 1.0
Release: 0%{?dist}
License: GPLv2+
Group: System Environment/Base
Source: %{name}-%{version}.tgz
Url: http://%{name}.sourceforge.net
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: selinux-policy-devel m4 make policycoreutils >= %{POLICYCOREUTILSVER}
Requires(pre): policycoreutils >= %{POLICYCOREUTILSVER} libsemanage >= 2.0.14-3

%description 
SELinux policy example

%files 
%dir /var/spool/%{name}
%dir %{_usr}/share/%{name}
%{_usr}/share/%{name}/%{name}.pp
%{_usr}/share/selinux/include/services/%{name}.if
%{_sbindir}/%{name}
%{_sysconfdir}/rc.d/init.d/%{name}

%description
Exapme Policy Package

%build
make 

%prep 
%setup

%install
# Build targeted policy
%{__rm} -fR %{buildroot}
make DESTDIR=%{buildroot} install

%clean
%{__rm} -fR %{buildroot}

%define saveFileContext() \
if [ -s /etc/selinux/config ]; then \
	. %{_sysconfdir}/selinux/config; \
	FILE_CONTEXT=%{_sysconfdir}/selinux/%1/contexts/files/file_contexts; \
	if [ "${SELINUXTYPE}" == %1 -a -f ${FILE_CONTEXT} ]; then \
		cp -f ${FILE_CONTEXT} ${FILE_CONTEXT}.%{name}; \
	fi \
fi;

%define relabel() \
. %{_sysconfdir}/selinux/config; \
FILE_CONTEXT=%{_sysconfdir}/selinux/%1/contexts/files/file_contexts; \
selinuxenabled; \
if [ $? == 0  -a "${SELINUXTYPE}" == %1 -a -f ${FILE_CONTEXT}.%{name} ]; then \
	fixfiles -C ${FILE_CONTEXT}.%{name} restore; \
	rm -f ${FILE_CONTEXT}.%name; \
fi;

%pre
%saveFileContext targeted

%post
semodule -s targeted -i /usr/share/%{name}/%{name}.pp
%relabel targeted

%preun
if [ $1 = 0 ]; then
%saveFileContext targeted
fi

%postun
if [ $1 = 0 ]; then
semodule -s targeted -r %{name}
%relabel targeted
fi

%changelog
* Thu Dec 20 2007 Dan Walsh <dwalsh@redhat.com> 3.2.5-3
- Initial Policy


[-- Attachment #3: example.spec.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

[-- Attachment #4: example.te --]
[-- Type: text/plain, Size: 1778 bytes --]

policy_module(example,1.0.0)

########################################
#
# Declarations
#

type example_t;
type example_exec_t;
domain_type(example_t)
init_daemon_domain(example_t, example_exec_t)

type example_script_exec_t;
init_script_type(example_script_exec_t)

type example_var_run_t;
files_pid_file(example_var_run_t)

type example_spool_t;
files_type(example_spool_t)

########################################
#
# example local policy
#

# Init script handling
domain_use_interactive_fds(example_t)

## internal communication is often done using fifo and unix sockets.
allow example_t self:fifo_file rw_file_perms;
allow example_t self:unix_stream_socket create_stream_socket_perms;

corecmd_search_sbin(example_t)

files_read_etc_files(example_t)

kernel_read_system_state(example_t)

libs_use_ld_so(example_t)
libs_use_shared_libs(example_t)

miscfiles_read_localization(example_t)

manage_dirs_pattern(example_t, example_var_run_t,  example_var_run_t)
manage_files_pattern(example_t, example_var_run_t,  example_var_run_t)
files_pid_filetrans(example_t,example_var_run_t, { file dir })

allow example_t example_spool_t:dir manage_dir_perms;
allow example_t example_spool_t:file manage_file_perms;
allow example_t example_spool_t:sock_file create_file_perms;
files_spool_filetrans(example_t,example_spool_t, { file dir sock_file })

sysnet_dns_name_resolve(example_t)
corenet_all_recvfrom_unlabeled(example_t)

allow example_t self:udp_socket { create_socket_perms listen };
corenet_udp_sendrecv_all_if(example_t)
corenet_udp_sendrecv_all_nodes(example_t)
corenet_udp_sendrecv_all_ports(example_t)
corenet_udp_bind_all_nodes(example_t)
corenet_udp_bind_monopd_port(example_t)

auth_use_nsswitch(example_t)

logging_send_syslog_msg(example_t)

mta_send_mail(example_t)

[-- Attachment #5: example.fc --]
[-- Type: text/plain, Size: 312 bytes --]


/usr/sbin/example	--	gen_context(system_u:object_r:example_exec_t,s0)

/etc/rc\.d/init\.d/example	--	gen_context(system_u:object_r:example_script_exec_t,s0)
/var/run/example\.pid		--	gen_context(system_u:object_r:example_var_run_t,s0)
/var/spool/example(/.*)?		gen_context(system_u:object_r:example_spool_t,s0)

[-- Attachment #6: example.spec.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

[-- Attachment #7: example.spec.sig.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

[-- Attachment #8: example.te.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

[-- Attachment #9: example.fc.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM

[Stephen Smalley]

On Fri, 2007-12-21 at 09:52 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Doing this I believe I found a bug in bug in SELinux,  that I am not
> sure how we fix.
> 
> Steps to produce bug.
> 
> Build and install
> 
> http://people.fedoraproject.org/~dwalsh/SELinux/example-1.0-0.fc9.src.rpm
> 
> This will install a daemon program
> 
> /usr/sbin/example
> /var/spool/example
> /etc/init.d/example
> 
> All of these should be labeled correctly
> 
> Now start the daemon
> # rpm -Uhv example-1.0-0.fc9.noarch.rpm
> # service example start
> 
> This will only create a pid file /var/run/example.pid
> 
> Now make sure everything is labeled correctly
> 
> # ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
> /var/run/example.pid
> - -rwxr-xr-x  root root system_u:object_r:example_script_exec_t
> /etc/init.d/example
> - -rwxr-xr-x  root root system_u:object_r:example_exec_t /usr/sbin/example
> - -rw-r--r--  root root system_u:object_r:example_var_run_t
> /var/run/example.pid
> drwxr-xr-x  root root system_u:object_r:example_spool_t /var/spool/example/
> 
> Touch a file in /var/spool/example to make sure rpm does not remove with
> the package
> 
> # touch /var/spool/example/example.tmp
> 
> Now I am going to test the uninstall of the package.
> 
> 
> rpm -e example
> 
> ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
> /var/run/example.pid
> ls: cannot access /usr/sbin/example: No such file or directory
> ls: cannot access /etc/init.d/example: No such file or directory
> - -rw-r--r--  root root system_u:object_r:unlabeled_t
> /var/run/example.pid
> drwxr-xr-x  root root system_u:object_r:var_spool_t    /var/spool/example/
> 
> # restorecon -R -v /var/run/example.pid
> # ls -lZ /var/run/example.pid
> - -rw-r--r--  root root system_u:object_r:unlabeled_t
> /var/run/example.pid
> 
> It leaves the pid file as unlabeled_t, this is because
> 
> /var/run/.*\.*pid	<<none>>
> 
> Which tells restorecon to not change any context on a pid file.  But
> leaving the file as unlabeled_t causes other problems.

Interestingly though, there are specific entries for specific pid files
in the .fc files.  In which case I'm not sure why we retain the above -
the original point of marking /var/run pid files with <<none>> was
because those files are runtime files and thus just labeled based on
type transitions when they are created, and we didn't want
setfiles/restorecon to clobber those labels.  But if we have specific
entries for the individual files (because they actually do have
meaningful and predictable names, unlike /tmp files), then we don't
really buy much by having the <<none>> entry.

> Now I reinstall the package
> 
> # rpm -Uhv
> /home/devel/dwalsh/sources/RPMS/noarch/example-1.0-0.fc9.noarch.rpm
> Preparing...                ###########################################
> [100%]
>    1:example                ###########################################
> [100%]
> /sbin/restorecon set context
> /var/run/example.pid->system_u:object_r:example_var_run_t:s0
> failed:'Permission denied'
> 
> AVC is generated
> 
> time->Thu Dec 20 19:28:50 2007
> type=PATH msg=audit(1198196930.130:1540): item=0
> name="/var/run/example.pid" inode=3178877 dev=fd:00 mode=0100644 ouid=0
> ogid=0 rdev=00:00 obj=system_u:object_r:example_var_run_t:s0
> type=CWD msg=audit(1198196930.130:1540):  cwd="/"
> type=SYSCALL msg=audit(1198196930.130:1540): arch=40000003 syscall=227
> success=no exit=-13 a0=bfcbd7e0 a1=1417c1 a2=ba1ed1e0 a3=27 items=1
> ppid=23898 pid=23928 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts2 comm="restorecon" exe="/sbin/setfiles"
> subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file

That doesn't seem to match the policy, since setfiles_t does have
relabelto for all file types, and it has relabelfrom for unlabeled_t
AFAICS.  And it has the attribute needed to relabel files with different
SELinux user identities.

> If I pipe this to audit2why
> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
> 	Was caused by:
> 		Unknown - would be allowed by active policy
> 		Possible mismatch between this policy and the one under which the
> audit message was generated.
> 		Possible mismatch between current in-memory boolean settings vs.
> permanent ones.

So userland's interpretation of the policy doesn't match the kernel's
interpretation, or they aren't actually seeing the same policy.  Not
good.

> If I run restorecon on it now, it is fine.

That's interesting - does it run in a different context when run
interactively than from rpm?
> 
> If I do the exact same steps above, but change the context on
> /var/run/example.pid to say bin_t.
> 
> The install happens successfully.

Hmmm..which seems to tie it to the fact that the file was unlabeled (or
more precisely, had an invalidated SID).  Yet the denial itself wasn't
on the unlabeled SID but on the new label.

> It seems that during the rpm update the policy in the kernel is
> different then when it completes.  All the postinstall is doing is
> 
> # semodule -s targeted -i example.pp
> followed by a fixfiles on the files in example.spec
> 
> Why this would work outside the rpm transaction but not inside is the
> bug.  Why does it work with the label of bin_t, but not when it is
> labeled unlabeled_t?

I agree it shouldn't differ, so this suggests a bug in the kernel's
handling of inodes with invalidated SIDs.

We should try to track that down regardless, but one thing that might
change the situation would be the old patch I had to retain invalidated
contexts in the SID table and then turn them back into valid SIDs upon
policy reload that make them valid once again.  That avoided the whole
unlabeled_t state for such files.  That patch actually had two logical
changes within it, one to support preservation of such invalidated
contexts and one to let privileged programs (ala rpm) set invalid
contexts in the first place (so that they could set down the context
before loading the policy module).  The latter part was the more
controversial piece and could be removed.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Fri, 2007-12-21 at 09:52 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Doing this I believe I found a bug in bug in SELinux,  that I am not
>> sure how we fix.
>>
>> Steps to produce bug.
>>
>> Build and install
>>
>> http://people.fedoraproject.org/~dwalsh/SELinux/example-1.0-0.fc9.src.rpm
>>
>> This will install a daemon program
>>
>> /usr/sbin/example
>> /var/spool/example
>> /etc/init.d/example
>>
>> All of these should be labeled correctly
>>
>> Now start the daemon
>> # rpm -Uhv example-1.0-0.fc9.noarch.rpm
>> # service example start
>>
>> This will only create a pid file /var/run/example.pid
>>
>> Now make sure everything is labeled correctly
>>
>> # ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
>> /var/run/example.pid
>> - -rwxr-xr-x  root root system_u:object_r:example_script_exec_t
>> /etc/init.d/example
>> - -rwxr-xr-x  root root system_u:object_r:example_exec_t /usr/sbin/example
>> - -rw-r--r--  root root system_u:object_r:example_var_run_t
>> /var/run/example.pid
>> drwxr-xr-x  root root system_u:object_r:example_spool_t /var/spool/example/
>>
>> Touch a file in /var/spool/example to make sure rpm does not remove with
>> the package
>>
>> # touch /var/spool/example/example.tmp
>>
>> Now I am going to test the uninstall of the package.
>>
>>
>> rpm -e example
>>
>> ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
>> /var/run/example.pid
>> ls: cannot access /usr/sbin/example: No such file or directory
>> ls: cannot access /etc/init.d/example: No such file or directory
>> - -rw-r--r--  root root system_u:object_r:unlabeled_t
>> /var/run/example.pid
>> drwxr-xr-x  root root system_u:object_r:var_spool_t    /var/spool/example/
>>
>> # restorecon -R -v /var/run/example.pid
>> # ls -lZ /var/run/example.pid
>> - -rw-r--r--  root root system_u:object_r:unlabeled_t
>> /var/run/example.pid
>>
>> It leaves the pid file as unlabeled_t, this is because
>>
>> /var/run/.*\.*pid	<<none>>
>>
>> Which tells restorecon to not change any context on a pid file.  But
>> leaving the file as unlabeled_t causes other problems.
> 
> Interestingly though, there are specific entries for specific pid files
> in the .fc files.  In which case I'm not sure why we retain the above -
> the original point of marking /var/run pid files with <<none>> was
> because those files are runtime files and thus just labeled based on
> type transitions when they are created, and we didn't want
> setfiles/restorecon to clobber those labels.  But if we have specific
> entries for the individual files (because they actually do have
> meaningful and predictable names, unlike /tmp files), then we don't
> really buy much by having the <<none>> entry.
> 
I am going to remove that mapping.  All domains that create a pid file
should have a file context that matches.

>> Now I reinstall the package
>>
>> # rpm -Uhv
>> /home/devel/dwalsh/sources/RPMS/noarch/example-1.0-0.fc9.noarch.rpm
>> Preparing...                ###########################################
>> [100%]
>>    1:example                ###########################################
>> [100%]
>> /sbin/restorecon set context
>> /var/run/example.pid->system_u:object_r:example_var_run_t:s0
>> failed:'Permission denied'
>>
>> AVC is generated
>>
>> time->Thu Dec 20 19:28:50 2007
>> type=PATH msg=audit(1198196930.130:1540): item=0
>> name="/var/run/example.pid" inode=3178877 dev=fd:00 mode=0100644 ouid=0
>> ogid=0 rdev=00:00 obj=system_u:object_r:example_var_run_t:s0
>> type=CWD msg=audit(1198196930.130:1540):  cwd="/"
>> type=SYSCALL msg=audit(1198196930.130:1540): arch=40000003 syscall=227
>> success=no exit=-13 a0=bfcbd7e0 a1=1417c1 a2=ba1ed1e0 a3=27 items=1
>> ppid=23898 pid=23928 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>> sgid=0 fsgid=0 tty=pts2 comm="restorecon" exe="/sbin/setfiles"
>> subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)
>> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
>>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
>> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
> 
> That doesn't seem to match the policy, since setfiles_t does have
> relabelto for all file types, and it has relabelfrom for unlabeled_t
> AFAICS.  And it has the attribute needed to relabel files with different
> SELinux user identities.
> 
>> If I pipe this to audit2why
>> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
>>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
>> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
>> 	Was caused by:
>> 		Unknown - would be allowed by active policy
>> 		Possible mismatch between this policy and the one under which the
>> audit message was generated.
>> 		Possible mismatch between current in-memory boolean settings vs.
>> permanent ones.
> 
> So userland's interpretation of the policy doesn't match the kernel's
> interpretation, or they aren't actually seeing the same policy.  Not
> good.
> 
>> If I run restorecon on it now, it is fine.
> 
> That's interesting - does it run in a different context when run
> interactively than from rpm?
>> If I do the exact same steps above, but change the context on
>> /var/run/example.pid to say bin_t.
>>
Yes I guess it does, rpm transisitions to setfiles_t while unconfined_t
stays as unconfined_t.

Although the kernel definitely understands the example_var_run_t is a
valid file context, when run from unconfined_t.

>> The install happens successfully.
> 
> Hmmm..which seems to tie it to the fact that the file was unlabeled (or
> more precisely, had an invalidated SID).  Yet the denial itself wasn't
> on the unlabeled SID but on the new label.
> 
>> It seems that during the rpm update the policy in the kernel is
>> different then when it completes.  All the postinstall is doing is
>>
>> # semodule -s targeted -i example.pp
>> followed by a fixfiles on the files in example.spec
>>
>> Why this would work outside the rpm transaction but not inside is the
>> bug.  Why does it work with the label of bin_t, but not when it is
>> labeled unlabeled_t?
> 
> I agree it shouldn't differ, so this suggests a bug in the kernel's
> handling of inodes with invalidated SIDs.
> 
> We should try to track that down regardless, but one thing that might
> change the situation would be the old patch I had to retain invalidated
> contexts in the SID table and then turn them back into valid SIDs upon
> policy reload that make them valid once again.  That avoided the whole
> unlabeled_t state for such files.  That patch actually had two logical
> changes within it, one to support preservation of such invalidated
> contexts and one to let privileged programs (ala rpm) set invalid
> contexts in the first place (so that they could set down the context
> before loading the policy module).  The latter part was the more
> controversial piece and could be removed.
> 

Of course the second part has always been requested by Red Hat/RPM
maintainers in order to have rpm do a better job of placing the file
context on disk in the first place.

semodule -r policy

causing things like processes to go wild with unlabeled_t and file
context becoming invalidated, so other confined domains, loose access is
a hinderence to using policy in rpm.  Since if I uninstall the apache
policy.  All apps that rely on the files will suddenly stop working.

I have seen processes go to 100 CPU utilization when they become
unlabeled_t.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHa+YdrlYvE4MpobMRAptPAJ0avXIkMHKDBnl7VBYrOzVL9xDR9gCfYW7W
WLRFWR8JfbXDuWyNQwIv670=
=oRLd
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I have been working on a example policy/rpm package to demontrate how to ship SELinux policy in an RPM

[Stephen Smalley]

On Fri, 2007-12-21 at 11:13 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Fri, 2007-12-21 at 09:52 -0500, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Doing this I believe I found a bug in bug in SELinux,  that I am not
> >> sure how we fix.
> >>
> >> Steps to produce bug.
> >>
> >> Build and install
> >>
> >> http://people.fedoraproject.org/~dwalsh/SELinux/example-1.0-0.fc9.src.rpm
> >>
> >> This will install a daemon program
> >>
> >> /usr/sbin/example
> >> /var/spool/example
> >> /etc/init.d/example
> >>
> >> All of these should be labeled correctly
> >>
> >> Now start the daemon
> >> # rpm -Uhv example-1.0-0.fc9.noarch.rpm
> >> # service example start
> >>
> >> This will only create a pid file /var/run/example.pid
> >>
> >> Now make sure everything is labeled correctly
> >>
> >> # ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
> >> /var/run/example.pid
> >> - -rwxr-xr-x  root root system_u:object_r:example_script_exec_t
> >> /etc/init.d/example
> >> - -rwxr-xr-x  root root system_u:object_r:example_exec_t /usr/sbin/example
> >> - -rw-r--r--  root root system_u:object_r:example_var_run_t
> >> /var/run/example.pid
> >> drwxr-xr-x  root root system_u:object_r:example_spool_t /var/spool/example/
> >>
> >> Touch a file in /var/spool/example to make sure rpm does not remove with
> >> the package
> >>
> >> # touch /var/spool/example/example.tmp
> >>
> >> Now I am going to test the uninstall of the package.
> >>
> >>
> >> rpm -e example
> >>
> >> ls -ldZ /usr/sbin/example /etc/init.d/example /var/spool/example/
> >> /var/run/example.pid
> >> ls: cannot access /usr/sbin/example: No such file or directory
> >> ls: cannot access /etc/init.d/example: No such file or directory
> >> - -rw-r--r--  root root system_u:object_r:unlabeled_t
> >> /var/run/example.pid
> >> drwxr-xr-x  root root system_u:object_r:var_spool_t    /var/spool/example/
> >>
> >> # restorecon -R -v /var/run/example.pid
> >> # ls -lZ /var/run/example.pid
> >> - -rw-r--r--  root root system_u:object_r:unlabeled_t
> >> /var/run/example.pid
> >>
> >> It leaves the pid file as unlabeled_t, this is because
> >>
> >> /var/run/.*\.*pid	<<none>>
> >>
> >> Which tells restorecon to not change any context on a pid file.  But
> >> leaving the file as unlabeled_t causes other problems.
> > 
> > Interestingly though, there are specific entries for specific pid files
> > in the .fc files.  In which case I'm not sure why we retain the above -
> > the original point of marking /var/run pid files with <<none>> was
> > because those files are runtime files and thus just labeled based on
> > type transitions when they are created, and we didn't want
> > setfiles/restorecon to clobber those labels.  But if we have specific
> > entries for the individual files (because they actually do have
> > meaningful and predictable names, unlike /tmp files), then we don't
> > really buy much by having the <<none>> entry.
> > 
> I am going to remove that mapping.  All domains that create a pid file
> should have a file context that matches.
> 
> >> Now I reinstall the package
> >>
> >> # rpm -Uhv
> >> /home/devel/dwalsh/sources/RPMS/noarch/example-1.0-0.fc9.noarch.rpm
> >> Preparing...                ###########################################
> >> [100%]
> >>    1:example                ###########################################
> >> [100%]
> >> /sbin/restorecon set context
> >> /var/run/example.pid->system_u:object_r:example_var_run_t:s0
> >> failed:'Permission denied'
> >>
> >> AVC is generated
> >>
> >> time->Thu Dec 20 19:28:50 2007
> >> type=PATH msg=audit(1198196930.130:1540): item=0
> >> name="/var/run/example.pid" inode=3178877 dev=fd:00 mode=0100644 ouid=0
> >> ogid=0 rdev=00:00 obj=system_u:object_r:example_var_run_t:s0
> >> type=CWD msg=audit(1198196930.130:1540):  cwd="/"
> >> type=SYSCALL msg=audit(1198196930.130:1540): arch=40000003 syscall=227
> >> success=no exit=-13 a0=bfcbd7e0 a1=1417c1 a2=ba1ed1e0 a3=27 items=1
> >> ppid=23898 pid=23928 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> >> sgid=0 fsgid=0 tty=pts2 comm="restorecon" exe="/sbin/setfiles"
> >> subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)
> >> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
> >>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
> >> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
> >> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
> > 
> > That doesn't seem to match the policy, since setfiles_t does have
> > relabelto for all file types, and it has relabelfrom for unlabeled_t
> > AFAICS.  And it has the attribute needed to relabel files with different
> > SELinux user identities.
> > 
> >> If I pipe this to audit2why
> >> type=AVC msg=audit(1198196930.130:1540): avc:  denied  { relabelto } for
> >>  pid=23928 comm="restorecon" name="example.pid" dev=dm-0 ino=3178877
> >> scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023
> >> tcontext=system_u:object_r:example_var_run_t:s0 tclass=file
> >> 	Was caused by:
> >> 		Unknown - would be allowed by active policy
> >> 		Possible mismatch between this policy and the one under which the
> >> audit message was generated.
> >> 		Possible mismatch between current in-memory boolean settings vs.
> >> permanent ones.
> > 
> > So userland's interpretation of the policy doesn't match the kernel's
> > interpretation, or they aren't actually seeing the same policy.  Not
> > good.
> > 
> >> If I run restorecon on it now, it is fine.
> > 
> > That's interesting - does it run in a different context when run
> > interactively than from rpm?
> >> If I do the exact same steps above, but change the context on
> >> /var/run/example.pid to say bin_t.
> >>
> Yes I guess it does, rpm transisitions to setfiles_t while unconfined_t
> stays as unconfined_t.
> 
> Although the kernel definitely understands the example_var_run_t is a
> valid file context, when run from unconfined_t.
> 
> >> The install happens successfully.
> > 
> > Hmmm..which seems to tie it to the fact that the file was unlabeled (or
> > more precisely, had an invalidated SID).  Yet the denial itself wasn't
> > on the unlabeled SID but on the new label.
> > 
> >> It seems that during the rpm update the policy in the kernel is
> >> different then when it completes.  All the postinstall is doing is
> >>
> >> # semodule -s targeted -i example.pp
> >> followed by a fixfiles on the files in example.spec
> >>
> >> Why this would work outside the rpm transaction but not inside is the
> >> bug.  Why does it work with the label of bin_t, but not when it is
> >> labeled unlabeled_t?
> > 
> > I agree it shouldn't differ, so this suggests a bug in the kernel's
> > handling of inodes with invalidated SIDs.
> > 
> > We should try to track that down regardless, but one thing that might
> > change the situation would be the old patch I had to retain invalidated
> > contexts in the SID table and then turn them back into valid SIDs upon
> > policy reload that make them valid once again.  That avoided the whole
> > unlabeled_t state for such files.  That patch actually had two logical
> > changes within it, one to support preservation of such invalidated
> > contexts and one to let privileged programs (ala rpm) set invalid
> > contexts in the first place (so that they could set down the context
> > before loading the policy module).  The latter part was the more
> > controversial piece and could be removed.
> > 
> 
> Of course the second part has always been requested by Red Hat/RPM
> maintainers in order to have rpm do a better job of placing the file
> context on disk in the first place.
> 
> semodule -r policy
> 
> causing things like processes to go wild with unlabeled_t and file
> context becoming invalidated, so other confined domains, loose access is
> a hinderence to using policy in rpm.  Since if I uninstall the apache
> policy.  All apps that rely on the files will suddenly stop working.
> 
> I have seen processes go to 100 CPU utilization when they become
> unlabeled_t.

I don't think my kernel patch actually helps with that (or on second
thought, with the problem you are having now). The kernel still treats
invalid contexts as unlabeled for permission checking purposes while
they remain invalid.  The only difference is that they can become valid
once again automatically if the policy module is re-inserted without
requiring them to be relabeled.

And the situation is worse for processes than for files.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.