I am currently writing a policy file for an application which listens to a particular port and also communicates with mysqld. During its start-up (from a script executed in init.d) I am getting the following AVCs:
================================= type=AVC msg=audit(1283028441.852:19): avc: denied { read } for pid=1868 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=AVC msg=audit(1283028441.851:18): avc: denied { write } for pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1283028441.852:19): arch=40000003 syscall=3 per=400000 success=no exit=-13 a0=6 a1=9d58864 a2=94 a3=0 items=0 ppid=1866 pid=1868 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) type=SYSCALL msg=audit(1283028441.851:18): arch=40000003 syscall=4 per=400000 success=no exit=-13 a0=7 a1=bf894480 a2=94 a3=bf894480 items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) type=AVC msg=audit(1283028441.863:20): avc: denied { write } for pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1283028441.863:20): arch=40000003 syscall=4 per=400000 success=no exit=-13 a0=7 a1=bf8945c0 a2=94 a3=bf8945c0 items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) =================================
Both pids 1868 and 1866 are related and spawned by the main application. I take it there is a pipe which needs to be created and accessible to both processes. How do I find out what pipe it is (name, location) and how do I prevent this AVCs from happening? Many thanks!
On 08/29/2010 12:36 AM, Mr Dash Four wrote:
I am currently writing a policy file for an application which listens to a particular port and also communicates with mysqld. During its start-up (from a script executed in init.d) I am getting the following AVCs:
================================= type=AVC msg=audit(1283028441.852:19): avc: denied { read } for pid=1868 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=AVC msg=audit(1283028441.851:18): avc: denied { write } for pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1283028441.852:19): arch=40000003 syscall=3 per=400000 success=no exit=-13 a0=6 a1=9d58864 a2=94 a3=0 items=0 ppid=1866 pid=1868 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) type=SYSCALL msg=audit(1283028441.851:18): arch=40000003 syscall=4 per=400000 success=no exit=-13 a0=7 a1=bf894480 a2=94 a3=bf894480 items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) type=AVC msg=audit(1283028441.863:20): avc: denied { write } for pid=1866 comm="voip_sandbox" path="pipe:[11951]" dev=pipefs ino=11951 scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1283028441.863:20): arch=40000003 syscall=4 per=400000 success=no exit=-13 a0=7 a1=bf8945c0 a2=94 a3=bf8945c0 items=0 ppid=1 pid=1866 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null) =================================
Both pids 1868 and 1866 are related and spawned by the main application. I take it there is a pipe which needs to be created and accessible to both processes. How do I find out what pipe it is (name, location) and how do I prevent this AVCs from happening? Many thanks!
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
Is 'rw_fifo_file_perms' custom-defined somewhere?
All I can see on the fifo_file is { append create execute getattr ioctl link lock mounton quotaon read relabelfrom relabelto rename setattr swapon unlink write }, of which, 'read' and 'write' are the relevant ones. If I do 'allow voip_sandbox_t self:fifo_file { read write }' would that be the same thing or am I missing something?
On 08/29/2010 01:45 PM, Mr Dash Four wrote:
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
Is 'rw_fifo_file_perms' custom-defined somewhere?
All I can see on the fifo_file is { append create execute getattr ioctl link lock mounton quotaon read relabelfrom relabelto rename setattr swapon unlink write }, of which, 'read' and 'write' are the relevant ones. If I do 'allow voip_sandbox_t self:fifo_file { read write }' would that be the same thing or am I missing something?
http://oss.tresys.com/projects/refpolicy/browser/policy/support/obj_perm_set...
line 241:
define(`rw_fifo_file_perms',`{ getattr open read write append ioctl lock }')
Basically a set of common permissions to read and write fifo files. Not quite the same as just { read write } but not too excessive either.
I always use "macros" where ever possible that will make policy maintenance much easier.
Is 'rw_fifo_file_perms' custom-defined somewhere?
All I can see on the fifo_file is { append create execute getattr ioctl link lock mounton quotaon read relabelfrom relabelto rename setattr swapon unlink write }, of which, 'read' and 'write' are the relevant ones. If I do 'allow voip_sandbox_t self:fifo_file { read write }' would that be the same thing or am I missing something?
http://oss.tresys.com/projects/refpolicy/browser/policy/support/obj_perm_set...
line 241:
define(`rw_fifo_file_perms',`{ getattr open read write append ioctl lock }')
Basically a set of common permissions to read and write fifo files. Not quite the same as just { read write } but not too excessive either.
That would do, thanks!
I always use "macros" where ever possible that will make policy maintenance much easier.
Maintenance - yes, but finding where it comes from and what it does (essential for people like me!) is a right nightmare!
Every time I stumble across something like this I have to do a 'grep' on the whole serefpolicy directory to see where it comes from and what it does - this does take time and I find it very frustrating, not to mention that this search is not always successful (there are macros with $1 and $2 in their names and finding this is not as straight forward job as it first seems!)
On 08/29/2010 02:30 PM, Mr Dash Four wrote:
Is 'rw_fifo_file_perms' custom-defined somewhere?
All I can see on the fifo_file is { append create execute getattr ioctl link lock mounton quotaon read relabelfrom relabelto rename setattr swapon unlink write }, of which, 'read' and 'write' are the relevant ones. If I do 'allow voip_sandbox_t self:fifo_file { read write }' would that be the same thing or am I missing something?
http://oss.tresys.com/projects/refpolicy/browser/policy/support/obj_perm_set...
line 241:
define(`rw_fifo_file_perms',`{ getattr open read write append ioctl lock }')
Basically a set of common permissions to read and write fifo files. Not quite the same as just { read write } but not too excessive either.
That would do, thanks!
I always use "macros" where ever possible that will make policy maintenance much easier.
Maintenance - yes, but finding where it comes from and what it does (essential for people like me!) is a right nightmare!
Every time I stumble across something like this I have to do a 'grep' on the whole serefpolicy directory to see where it comes from and what it does - this does take time and I find it very frustrating, not to mention that this search is not always successful (there are macros with $1 and $2 in their names and finding this is not as straight forward job as it first seems!)
After a while you know these things without looking them up. That why it is also important to use consistent interface names. So that you can easily make the right guess.
As for looking stuff up, i use eclipse-slide. Basically i have refpolicy imported into slide and build in slide that will expose the macros so you can just hover over them and see their contents or alter click and choose open declaration or just click them and look in the declaration pane. Theres also a filter window which lets you easily search for interfaces.
But again, after a while, one just knows what to use. the refpolicy project tree is not so big. except the services section which has quite a lot of modules.
As for looking stuff up, i use eclipse-slide. Basically i have refpolicy imported into slide and build in slide that will expose the macros so you can just hover over them and see their contents or alter click and choose open declaration or just click them and look in the declaration pane. Theres also a filter window which lets you easily search for interfaces.
Bummer! I use Eclipse extensively in my everyday job (as well as at home) and that is the first time I've read about eclipse-slide!
Google reveals this - http://oss.tresys.com/projects/slide/wiki/download - and from this it seems a pretty handy tool to have. Does it resolve macros with $1 and/or $2 in their names (like corenet_bind_dns_port -> corenet_bind_$1_port for example)?
On 08/29/2010 02:55 PM, Mr Dash Four wrote:
As for looking stuff up, i use eclipse-slide. Basically i have refpolicy imported into slide and build in slide that will expose the macros so you can just hover over them and see their contents or alter click and choose open declaration or just click them and look in the declaration pane. Theres also a filter window which lets you easily search for interfaces.
Bummer! I use Eclipse extensively in my everyday job (as well as at home) and that is the first time I've read about eclipse-slide!
Google reveals this - http://oss.tresys.com/projects/slide/wiki/download
- and from this it seems a pretty handy tool to have. Does it resolve
macros with $1 and/or $2 in their names (like corenet_bind_dns_port -> corenet_bind_$1_port for example)?
Not like that ( that is not how the corenet interfaces are used) but for example if you hover over an interface call for example files_search_etc() it will tell you in a tooltip what parameters it takes (in this example $1 is domain)
But also with the $* variables once you get familiar with policy you basically know what parameters are needed to accomplish a valid access vector or set of access vectors.
The corenet interfaces are generated automatically when you declare a port type. So these interfaces are very consistent (each port type as the same set of interfaces to use. The only difference is the type prefix in the interface names.
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
This worked, though I get the following AVC when starting the process:
type=AVC msg=audit(1283088703.670:16403): avc: denied { execmem } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process type=SYSCALL msg=audit(1283088703.670:16403): arch=40000003 syscall=90 per=400000 success=no exit=-13 a0=8e997d4 a1=bfc01000 a2=bfc00000 a3=1ff000 items=0 ppid=1845 pid=1847 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
Even though the 2 spawned processes are still in memory (though nothing works) when I try to terminate the application nothing happens and when I try to reboot I get this in the audit log:
type=AVC msg=audit(1283088703.670:16404): avc: denied { signal } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process
Tried to add 'allow voip_sandbox_t self:process { execmem signal };' but that did not help one iota - I am getting the same avcs!
On 08/29/2010 05:00 PM, Mr Dash Four wrote:
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
This worked, though I get the following AVC when starting the process:
type=AVC msg=audit(1283088703.670:16403): avc: denied { execmem } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process type=SYSCALL msg=audit(1283088703.670:16403): arch=40000003 syscall=90 per=400000 success=no exit=-13 a0=8e997d4 a1=bfc01000 a2=bfc00000 a3=1ff000 items=0 ppid=1845 pid=1847 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
Even though the 2 spawned processes are still in memory (though nothing works) when I try to terminate the application nothing happens and when I try to reboot I get this in the audit log:
type=AVC msg=audit(1283088703.670:16404): avc: denied { signal } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process
Tried to add 'allow voip_sandbox_t self:process { execmem signal };' but that did not help one iota - I am getting the same avcs!
That should not happen does sesearch know the rules?
sesearch -SC --allow -s voip_sandbox_t -t voip_sandbox_t -c process -p execmem
make sure that the rules is loaded
That should not happen does sesearch know the rules?
sesearch -SC --allow -s voip_sandbox_t -t voip_sandbox_t -c process -p execmem
make sure that the rules is loaded
My bad! Forgot to include the new version of the module in the final build. It works as expected now - got two more AVCs (setsched and getattr on a shared MySQL file loading charsets), but I was expecting this sort of thing.
On 08/29/2010 05:00 PM, Mr Dash Four wrote:
its a fifo_file on device pipefs with name/path: pipe:[11951]
This type of internal communication is very common. We use the following policy for this:
allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
This worked, though I get the following AVC when starting the process:
type=AVC msg=audit(1283088703.670:16403): avc: denied { execmem } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process type=SYSCALL msg=audit(1283088703.670:16403): arch=40000003 syscall=90 per=400000 success=no exit=-13 a0=8e997d4 a1=bfc01000 a2=bfc00000 a3=1ff000 items=0 ppid=1845 pid=1847 auid=0 uid=496 gid=496 euid=496 suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1 comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox" subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
Even though the 2 spawned processes are still in memory (though nothing works) when I try to terminate the application nothing happens and when I try to reboot I get this in the audit log:
type=AVC msg=audit(1283088703.670:16404): avc: denied { signal } for pid=1847 comm="voip_sandbox" scontext=unconfined_u:system_r:voip_sandbox_t:s0 tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process
Tried to add 'allow voip_sandbox_t self:process { execmem signal };' but that did not help one iota - I am getting the same avcs!
writing policy requires testing. i usually do my testing in permissive mode or with permissive domains.
basically in my initial policy i declare type for know object and subjects, i make the types usable. Then i add file context specifications so that the objects are labelled properly. in my initial policy i also define the domain transitions.
Then i usually test in permissive mode. collect as many AVC denials as i can and then translate them into human readable policy and extend the policy module, rebuild, reload and start over again, test, collect, extend, build, install etc.
writing policy requires testing. i usually do my testing in permissive mode or with permissive domains.
basically in my initial policy i declare type for know object and subjects, i make the types usable. Then i add file context specifications so that the objects are labelled properly. in my initial policy i also define the domain transitions.
Then i usually test in permissive mode. collect as many AVC denials as i can and then translate them into human readable policy and extend the policy module, rebuild, reload and start over again, test, collect, extend, build, install etc.
Good idea that - switching to permissive mode - as obvious as it might be, I never thought of that before. Noted!
As for the policy, I haven't yet defined all port interactions yet - needed to see whether the local binding with mysql would work first before I plunge myself and do the rest. I also wish to introduce the restriction for this program to operate on 2 different net interfaces (with the appropriate port rules for each!), so I haven't got that far yet.
selinux@lists.fedoraproject.org