11:18 p.m.
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
11:38 p.m.
selinux.funchords(a)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(a)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.
12:18 a.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
Richard Hally - rhally(a)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?
--
Robb Topolski (selinux.funchords(a)spameater.org)
http://www.funchords.com
8:46 a.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
On Tue, 2005-12-20 at 22:18 -0800, selinux.funchords(a)spameater.org
wrote:
Richard Hally - rhally(a)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
--
Stephen Smalley
National Security Agency
2:29 p.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
selinux.funchords(a)spameater.org wrote:
Richard Hally - rhally(a)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
--
8:40 p.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
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.
--
Bob Nichols Yes, "NOSPAM" is really part of my email address.
6:31 a.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
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.
--
9 a.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
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.
--
Stephen Smalley
National Security Agency
1:11 p.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
On 1/3/06, Stephen Smalley <sds(a)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...
6:35 p.m.
New subject: Curious Behavior doing routine redirection of ping output to (selinux: message 2 of 12) file...
On Wednesday 04 January 2006 06:11, Gregory Maxwell <gmaxwell(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6636
days inactive
6700
days old
selinux@lists.fedoraproject.org
9 comments
7 participants
participants (7)
-
Daniel J Walsh -
Gregory Maxwell -
Richard Hally -
Robert Nichols -
Russell Coker -
selinux.funchords＠spameater.org -
Stephen Smalley