Selfmade policy not getting enforced on Fedora9

[Stefan Schleifer]

Hey guys,

As you might guess, I've a problem with my SELinux-policy under Fedora  
9.

I created a little test application 'demo' which reads some text from  
stdin and writes it in a config file /etc/hackbar/config.txt.

Afterwarts, I developed a policy with types demo_t, demo_exec_t und  
demo_etc_t and allowed demo_exec_to to read/write demo_etc_t.  
Everything's fine.

For testing purposes I changed /etc/hackbar/config.txt to type etc_t  
which demo_exec_t shouldn't be able to access as there doesn't exist  
an allow demo_exec_t r/w etc_t.


[stefan@localhost policy]$ ls -Z /usr/local/bin/demo
-rwsr-sr-x   root   root   system_u:object_r:demo_exec_t:s0 /usr/local/ 
bin/demo
[stefan@localhost policy]$ ls -Z /etc/hackbar/config.txt
-rwxr-xr-x   root   root   system_u:object_r:etc_t:s0 /etc/hackbar/ 
config.txt


Again I ran the application but it is still allowed to change that  
file?!


[stefan@localhost policy]$ /usr/local/bin/demo
Enter text: foobar
Read from file: foobar


Regarding to standard UNIX permissions access should be granted as the  
demo-app has suid set, but shouldn't SELinux permitt access anyway in  
this case?

SELinux is in enforcing mode.


[stefan@localhost policy]$ /usr/sbin/sestatus
SELinux status:			enabled
SELinuxfs mount:			/selinux
Current mode:			enforcing
Mode from config file:		enforcing
Policy version:			22
Policy from config file:		targeted


I'm rather confused...

best regards,
Stefan

[David P. Quigley]

On Wed, 2008-05-28 at 20:18 +0200, Stefan Schleifer wrote:
>  Hey guys,
>  
>  As you might guess, I've a problem with my SELinux-policy under Fedora  
>  9.
>  
>  I created a little test application 'demo' which reads some text from  
>  stdin and writes it in a config file /etc/hackbar/config.txt.
>  
>  Afterwarts, I developed a policy with types demo_t, demo_exec_t und  
>  demo_etc_t and allowed demo_exec_to to read/write demo_etc_t.  
>  Everything's fine.
>  
>  For testing purposes I changed /etc/hackbar/config.txt to type etc_t  
>  which demo_exec_t shouldn't be able to access as there doesn't exist  
>  an allow demo_exec_t r/w etc_t.
>  
>  
>  [stefan@localhost policy]$ ls -Z /usr/local/bin/demo
>  -rwsr-sr-x   root   root   system_u:object_r:demo_exec_t:s0 /usr/local/ 
>  bin/demo
>  [stefan@localhost policy]$ ls -Z /etc/hackbar/config.txt
>  -rwxr-xr-x   root   root   system_u:object_r:etc_t:s0 /etc/hackbar/ 
>  config.txt
>  
>  
>  Again I ran the application but it is still allowed to change that  
>  file?!
>  
>  
>  [stefan@localhost policy]$ /usr/local/bin/demo
>  Enter text: foobar
>  Read from file: foobar
>  
>  
>  Regarding to standard UNIX permissions access should be granted as the  
>  demo-app has suid set, but shouldn't SELinux permitt access anyway in  
>  this case?
>  
>  SELinux is in enforcing mode.
>  
>  
>  [stefan@localhost policy]$ /usr/sbin/sestatus
>  SELinux status:			enabled
>  SELinuxfs mount:			/selinux
>  Current mode:			enforcing
>  Mode from config file:		enforcing
>  Policy version:			22
>  Policy from config file:		targeted
>  
>  
>  I'm rather confused...
>  
>  best regards,
>  Stefan
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
If possible could you post your policy? Also are you sure that your
program is running in demo_t?

Dave

[Eric Paris]

On Wed, 2008-05-28 at 20:18 +0200, Stefan Schleifer wrote:
>  Hey guys,
>  
>  As you might guess, I've a problem with my SELinux-policy under Fedora  
>  9.
>  
>  I created a little test application 'demo' which reads some text from  
>  stdin and writes it in a config file /etc/hackbar/config.txt.
>  
>  Afterwarts, I developed a policy with types demo_t, demo_exec_t und  
>  demo_etc_t and allowed demo_exec_to to read/write demo_etc_t.  
>  Everything's fine.
>  
>  For testing purposes I changed /etc/hackbar/config.txt to type etc_t  
>  which demo_exec_t shouldn't be able to access as there doesn't exist  
>  an allow demo_exec_t r/w etc_t.
>  
>  
>  [stefan@localhost policy]$ ls -Z /usr/local/bin/demo
>  -rwsr-sr-x   root   root   system_u:object_r:demo_exec_t:s0 /usr/local/ 
>  bin/demo
>  [stefan@localhost policy]$ ls -Z /etc/hackbar/config.txt
>  -rwxr-xr-x   root   root   system_u:object_r:etc_t:s0 /etc/hackbar/ 
>  config.txt
>  
>  
>  Again I ran the application but it is still allowed to change that  
>  file?!
>  
>  
>  [stefan@localhost policy]$ /usr/local/bin/demo
>  Enter text: foobar
>  Read from file: foobar
>  
>  
>  Regarding to standard UNIX permissions access should be granted as the  
>  demo-app has suid set, but shouldn't SELinux permitt access anyway in  
>  this case?
>  
>  SELinux is in enforcing mode.
>  
>  
>  [stefan@localhost policy]$ /usr/sbin/sestatus
>  SELinux status:			enabled
>  SELinuxfs mount:			/selinux
>  Current mode:			enforcing
>  Mode from config file:		enforcing
>  Policy version:			22
>  Policy from config file:		targeted
>  
>  
>  I'm rather confused... 
Are you sure you have the right transition rule from whatever you shell
runs as ?unconfined_t? to demo_t if you run a demo_exec_t binary?  What
to you see from ps -efZ | grep demo while your program is running??

-Eric

[Daniel J Walsh]

Stefan Schleifer wrote:
>  Hey guys,
>  
>  As you might guess, I've a problem with my SELinux-policy under Fedora 9.
>  
>  I created a little test application 'demo' which reads some text from
>  stdin and writes it in a config file /etc/hackbar/config.txt.
>  
>  Afterwarts, I developed a policy with types demo_t, demo_exec_t und
>  demo_etc_t and allowed demo_exec_to to read/write demo_etc_t.
>  Everything's fine.
>  
>  For testing purposes I changed /etc/hackbar/config.txt to type etc_t
>  which demo_exec_t shouldn't be able to access as there doesn't exist an
>  allow demo_exec_t r/w etc_t.
>  
>  
>  [stefan@localhost policy]$ ls -Z /usr/local/bin/demo
>  -rwsr-sr-x   root   root   system_u:object_r:demo_exec_t:s0
>  /usr/local/bin/demo
>  [stefan@localhost policy]$ ls -Z /etc/hackbar/config.txt
>  -rwxr-xr-x   root   root   system_u:object_r:etc_t:s0
>  /etc/hackbar/config.txt
>  
>  
>  Again I ran the application but it is still allowed to change that file?!
>  
>  
>  [stefan@localhost policy]$ /usr/local/bin/demo
>  Enter text: foobar
>  Read from file: foobar
>  
>  
>  Regarding to standard UNIX permissions access should be granted as the
>  demo-app has suid set, but shouldn't SELinux permitt access anyway in
>  this case?
>  
>  SELinux is in enforcing mode.
>  
>  
>  [stefan@localhost policy]$ /usr/sbin/sestatus
>  SELinux status:            enabled
>  SELinuxfs mount:            /selinux
>  Current mode:            enforcing
>  Mode from config file:        enforcing
>  Policy version:            22
>  Policy from config file:        targeted
>  
>  
>  I'm rather confused...
>  
>  best regards,
>  Stefan
>  
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
You need to define a
transition rule from the domain that is executing
the demo application.

So if you are running as unconfined_t you will need a rule like

domtrans_pattern(unconfined_t, demo_exec_t, demo_t)
role unconfined_r types demo_t;

[Stefan Schleifer]

On May 28, 2008, at 8:44 PM, Daniel J Walsh wrote:
>  You need to define a transition rule from the domain that is
> executing
>  the demo application.
>
>  So if you are running as unconfined_t you will need a rule like
>
>  domtrans_pattern(unconfined_t, demo_exec_t, demo_t)
>  role unconfined_r types demo_t; 
Hey,

You folks rock, thx a bunch. I forget the transition rule. As  
suggested, I added:


domain_auto_trans(unconfined_t, demo_exec_t, demo_t);


and now the app runs as demo_t:


[stefan@localhost policy]$ ps -efZ | grep demo
unconfined_u:unconfined_r:demo_t:s0-s0:c0.c1023 root 2856 2510 0 20:56  
pts/2 00:00:00 /usr/local/bin/demo


However, when I set SELinux to enforcing mode again, the app produces  
a seg fault, doesn't even coming to the point, where it writes to the  
file. Furthermore, the SELinux Troubleshooter doesn't alert me about  
having blocked something..

May I dare to ask, what's still missing?


The policy as a whole:


policy_module(demo,1.0.0)

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

type demo_t;
type demo_exec_t;
application_domain(demo_t, demo_exec_t);
domain_auto_trans(unconfined_t, demo_exec_t, demo_t);
role unconfined_r types demo_t;
role system_r types demo_t;

require {
	type unconfined_t;
	role unconfined_r;
}

type demo_tmp_t;
files_tmp_file(demo_tmp_t)

type demo_etc_rw_t;
files_type(demo_etc_rw_t)

########################################
#
# demo local policy
#

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

files_read_etc_files(demo_t)

libs_use_ld_so(demo_t)
libs_use_shared_libs(demo_t)

miscfiles_read_localization(demo_t)


allow demo_t demo_tmp_t:file manage_file_perms;
allow demo_t demo_tmp_t:dir create_dir_perms;
files_tmp_filetrans(demo_t,demo_tmp_t, { file dir })

allow demo_t demo_etc_rw_t:file manage_file_perms;
allow demo_t demo_etc_rw_t:dir manage_dir_perms;
files_etc_filetrans(demo_t,demo_etc_rw_t, { file dir })

optional_policy(`
	gen_require(`
		type user_t;
		type user_devpts_t;
		type user_tty_device_t;
		role user_r;
	')

	demo_run(user_t, user_r, { user_tty_device_t user_devpts_t })
')


Many thanks,
Stefan

[Stefan Schleifer]

On May 28, 2008, at 9:23 PM, Stefan Schleifer wrote:
>  Hey,
>
>  You folks rock, thx a bunch. I forget the transition rule. As  
>  suggested, I added:
>
>
>  domain_auto_trans(unconfined_t, demo_exec_t, demo_t);
>
>
>  and now the app runs as demo_t:
>
>
>  [stefan@localhost policy]$ ps -efZ | grep demo
>  unconfined_u:unconfined_r:demo_t:s0-s0:c0.c1023 root 2856 2510 0  
>  20:56 pts/2 00:00:00 /usr/local/bin/demo
>
>  (...) 

Hi,

After running semodule -DB & semodule -B (as suggested by Daniel), I  
got a few messages in /var/log/audit/audit.log and managed to modify  
the policy in a way it works now.

Closing, many many thanks to your quick and, of course, very helpful  
answers.

Thx a lot!

Best regards,
Stefan