I'm not exactly a "newbie," but I'm diving a lot deeper than I ever have. This one has me a little wrapped around the axel, and if someone could help clear the fog, I'd appreciate it.
The short version: I'm trying to redirect the output of ping to a file. I get a 0 byte file as a result.
Where I am now: When selinux is permissive, it works as I expect it to.
When this started, I had no idea that selinux was running or even what it was, exactly (I've been running this system for about two weeks). I've learned a lot since then. But I haven't figured out how to do anything other than flip bits on existing boolean rules and change the sestatus mode. For example, how do I fix the above problem?
Current version: 2.6.14-1.1653_FC4 with selinux in targeted/enforced.
When this began, I posted a message to www.fedoraforum.org ( http://www.fedoraforum.org/forum/showthread.php?t=88238 ) with the title, "BASH: How to redirect ping output to file?"
Later, I found this from from /var/log/audit/audit.log ... type=AVC msg=audit(1134599953.748:32): avc: denied { write } for pid=5503 comm="ping" name="pingoutput2" dev=dm-0 ino=916895 scontext=root:system_r:ping_t tcontext=root:object_r:user_home_t tclass=file type=SYSCALL msg=audit(1134599953.748:32): arch=40000003 syscall=11 success=yes exit=0 a0=8d64360 a1=8d56400 a2=8d51520 a3=1 items=2 pid=5503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ping" exe="/bin/ping" type=AVC_PATH msg=audit(1134599953.748:32): path="/root/pingoutput2" type=CWD msg=audit(1134599953.748:32): cwd="/root" type=PATH msg=audit(1134599953.748:32): item=0 name="/bin/ping" flags=101 inode=5499653 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1134599953.748:32): item=1 flags=101 inode=5892482 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
... and I discovered the commands audit2why and audit2allow, which has this example in the audit2allow man pages ...
$ cd /etc/selinux/$(SELINUXTYPE)/src/policy $ /usr/bin/audit2allow -i < /var/log/audit/audit.log >> domains/misc/local.te <review domains/misc/local.te and customize as desired> $ make load
... and that's where my zero-byte stack blows.
I have no src directory under /etc/selinux/targeted, nor do I have anything at all on my system named domains. Still, I tried to follow the advice by mdkir'ing the necessary directories and creating a local.te file with the recommended "allow ping_t user_home_t:file write;" line in it.
Then I typed 'make load' and I really think I actually heard something laugh at me.
This is the way I learn best, and this isn't anything more than a curiousity to me. But from what I've told you so far, can you point me into the right direction?
I did search the archive for this list, as well as the FC3 (which also seemed to point to these directories that I don't have).
Thanks!
Robb Topolski robb(at)funchords(dot)com http://www.funchords.com
selinux.funchords@spameater.org wrote:
I'm not exactly a "newbie," but I'm diving a lot deeper than I ever have. This one has me a little wrapped around the axel, and if someone could help clear the fog, I'd appreciate it.
The short version: I'm trying to redirect the output of ping to a file. I get a 0 byte file as a result.
Where I am now: When selinux is permissive, it works as I expect it to.
When this started, I had no idea that selinux was running or even what it was, exactly (I've been running this system for about two weeks). I've learned a lot since then. But I haven't figured out how to do anything other than flip bits on existing boolean rules and change the sestatus mode. For example, how do I fix the above problem?
Current version: 2.6.14-1.1653_FC4 with selinux in targeted/enforced.
When this began, I posted a message to www.fedoraforum.org ( http://www.fedoraforum.org/forum/showthread.php?t=88238 ) with the title, "BASH: How to redirect ping output to file?"
Later, I found this from from /var/log/audit/audit.log ... type=AVC msg=audit(1134599953.748:32): avc: denied { write } for pid=5503 comm="ping" name="pingoutput2" dev=dm-0 ino=916895 scontext=root:system_r:ping_t tcontext=root:object_r:user_home_t tclass=file type=SYSCALL msg=audit(1134599953.748:32): arch=40000003 syscall=11 success=yes exit=0 a0=8d64360 a1=8d56400 a2=8d51520 a3=1 items=2 pid=5503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ping" exe="/bin/ping" type=AVC_PATH msg=audit(1134599953.748:32): path="/root/pingoutput2" type=CWD msg=audit(1134599953.748:32): cwd="/root" type=PATH msg=audit(1134599953.748:32): item=0 name="/bin/ping" flags=101 inode=5499653 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1134599953.748:32): item=1 flags=101 inode=5892482 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
... and I discovered the commands audit2why and audit2allow, which has this example in the audit2allow man pages ...
$ cd /etc/selinux/$(SELINUXTYPE)/src/policy $ /usr/bin/audit2allow -i < /var/log/audit/audit.log >> domains/misc/local.te <review domains/misc/local.te and customize as desired> $ make load
... and that's where my zero-byte stack blows.
I have no src directory under /etc/selinux/targeted, nor do I have anything at all on my system named domains. Still, I tried to follow the advice by mdkir'ing the necessary directories and creating a local.te file with the recommended "allow ping_t user_home_t:file write;" line in it. Then I typed 'make load' and I really think I actually heard something laugh at me. This is the way I learn best, and this isn't anything more than a curiousity to me. But from what I've told you so far, can you point me into the right direction?
I did search the archive for this list, as well as the FC3 (which also seemed to point to these directories that I don't have).
Thanks!
Robb Topolski robb(at)funchords(dot)com http://www.funchords.com
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Looks like you need to download the corresponding source for the policy you are running e.g. selinux-policy-targeted-source for that audit2allow and make load to work.
Richard Hally - rhally@mindspring.com wrote:
Looks like you need to download the corresponding source for the policy you are running e.g. selinux-policy-targeted-source for that audit2allow and make load to work.
... and that works! Thanks!
Any idea why the rule is needed for a redirection by a ping command run by the root account? And if this is a FAQ, where is the best place to cut my teeth on this?
On Tue, 2005-12-20 at 22:18 -0800, selinux.funchords@spameater.org wrote:
Richard Hally - rhally@mindspring.com wrote:
Looks like you need to download the corresponding source for the policy you are running e.g. selinux-policy-targeted-source for that audit2allow and make load to work.
... and that works! Thanks!
Any idea why the rule is needed for a redirection by a ping command run by the root account? And if this is a FAQ, where is the best place to cut my teeth on this?
http://selinux.sourceforge.net/resources.php3
selinux.funchords@spameater.org wrote:
Richard Hally - rhally@mindspring.com wrote:
Looks like you need to download the corresponding source for the policy you are running e.g. selinux-policy-targeted-source for that audit2allow and make load to work.
... and that works! Thanks!
Any idea why the rule is needed for a redirection by a ping command run by the root account? And if this is a FAQ, where is the best place to cut my teeth on this?
ping runs under the ping_t domain and it is not allowed to write to the home dir. When you redirect in shell, shell has the application open the file which is not allowed. A hack to get around this problem is
ping XYZ | cat > /home/dwalsh/myping
Daniel J Walsh wrote:
ping runs under the ping_t domain and it is not allowed to write to the home dir. When you redirect in shell, shell has the application open the file which is not allowed. A hack to get around this problem is
ping XYZ | cat > /home/dwalsh/myping
It's actually the shell that opens the file for input or output redirection, so apparently SELinux is denying a write to a file that is already open for writing. Curious.
Robert Nichols wrote:
Daniel J Walsh wrote:
ping runs under the ping_t domain and it is not allowed to write to the home dir. When you redirect in shell, shell has the application open the file which is not allowed. A hack to get around this problem is
ping XYZ | cat > /home/dwalsh/myping
It's actually the shell that opens the file for input or output redirection, so apparently SELinux is denying a write to a file that is already open for writing. Curious.
That would seem logical, but from the kernel's perspective it looks like the ping command is opening the file on redirection. IE Stdout gets replaced with the write to the file. SELinux blocks on read/write not open.
On Thu, 2005-12-22 at 20:40 -0600, Robert Nichols wrote:
Daniel J Walsh wrote:
ping runs under the ping_t domain and it is not allowed to write to the home dir. When you redirect in shell, shell has the application open the file which is not allowed. A hack to get around this problem is
ping XYZ | cat > /home/dwalsh/myping
It's actually the shell that opens the file for input or output redirection, so apparently SELinux is denying a write to a file that is already open for writing. Curious.
SELinux rechecks access to open file descriptors when they are inherited across execve (if the security context of the process is changing, e.g. due to a domain transition, as in this case) and when they are transferred via local IPC. That is necessary to control the propagation of access rights in the system, required for mandatory access control. SELinux also rechecks access upon use (e.g. read(2) and write(2)) when possible to support limited revocation upon policy changes and object relabels, but revocation is difficult to support completely.
On 1/3/06, Stephen Smalley sds@tycho.nsa.gov wrote:
ping XYZ | cat > /home/dwalsh/myping
It's actually the shell that opens the file for input or output redirection, so apparently SELinux is denying a write to a file that is already open for writing. Curious.
SELinux rechecks access to open file descriptors when they are inherited across execve (if the security context of the process is changing, e.g. due to a domain transition, as in this case) and when they are transferred via local IPC. That is necessary to control the propagation of access rights in the system, required for mandatory access control. SELinux also rechecks access upon use (e.g. read(2) and write(2)) when possible to support limited revocation upon policy changes and object relabels, but revocation is difficult to support completely.
Would it be inappropriate add a compile time flag to bash to cause such redirection to always bounce through the shell? Obviously there would be a performance hit... but the mysterious failure is probably worse...
On Wednesday 04 January 2006 06:11, Gregory Maxwell gmaxwell@gmail.com wrote:
Would it be inappropriate add a compile time flag to bash to cause such redirection to always bounce through the shell? Obviously there would be a performance hit... but the mysterious failure is probably worse...
Mysterious failures are a bad thing. But the performance hit of proxying the data would also be bad.
Also note that there are some unusual features that some programs may rely on, for example when you see the following you may think that the file is append-only:
program > output
However that is not the case. The program can seek in the file, EG it can seek back to 0 to re-write the file if it wishes.
program < input
The above command permits seeking in the input file to read from different locations.
Some programs rely on this type of functionality, for example the mpg123 program to play MP3 files would do exactly that. Commands such as "zcat file.mp3.gz | mpg123 -" didn't work because seeks failed on the pipe. I wrote a patch for mpg123 that used fopen() and fseek() as the stdio buffers were large enough to allow the 100 byte reverse seeks that mpg123 relied on.
Tracking down many programs that are similarly buggy and writing work-arounds for them would not be fun.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Gregory Maxwell -
Richard Hally -
Robert Nichols -
Russell Coker -
selinux.funchords＠spameater.org -
Stephen Smalley