denied open of /dev/null for reading [SOLVED]
Posted: Mon Jul 13, 2015 2:30 pm
denied open of /dev/null for reading
=================================================
Yes, that is the issue behind this snippet from my post on Gentoo Forums:
A Tentative at dillo-3.1-dev ebuild
https://forums.gentoo.org/viewtopic-t-1021878.html
which I am reposting here:
---
... after running:
...
You probably will not have this temporary failure like mine:
But read about that, on:
Grsecurity Forums
NOTE: That is the link to this topic which I am now writing.
But rather (after I fixed the RBAC policy for the strange case):
But the autogen.sh wasn't too verbose, really.
...
That part only is of concern for grsec deployment.
How did I, as I write above, "fixed the RBAC policy for the strange case" and why I think it is strange (but of course, I could be wrong, I'm not an expert by any measure). And what were the exact denie lines in my logs?
This is what I saw in the /var/log/messages when I tried to run autogen.sh:
Every time that I would try, I would get four of such messages exactly.
And, apparently, the only thing that "solved" this (I don't think, but I am no expert, so I could be wrong):
In the role:
I changed that lline to:
Looking it up more closely. No. That is not strange. I see other lines reading and writing to /dev/null .
Sorry. All is fine here. (And I thought I had a strange issue.)
But I see other subjects in various roles reading and writing to /dev/null:
:egrep -B30 '\/dev\/null[[:space:]]{1,10}rw' /etc/grsec/policy | grep -B1 subject:
Sorry!
=================================================
Yes, that is the issue behind this snippet from my post on Gentoo Forums:
A Tentative at dillo-3.1-dev ebuild
https://forums.gentoo.org/viewtopic-t-1021878.html
which I am reposting here:
---
... after running:
- Code: Select all
$ cd ~/Test.d/dillo-3.1.0_pre20150712
$ ./autogen.sh
...
You probably will not have this temporary failure like mine:
- Code: Select all
ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $ ./autogen.sh
aclocal found
autoheader found
autoconf found
automake found
[Checks passed]
Generating...
sh: /dev/null: Permission denied
autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4
aclocal-1.15: error: echo failed with exit status: 1
sh: /dev/null: Permission denied
autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4
autoheader-2.69: '/usr/bin/autom4te-2.69' failed with exit status: 1
sh: /dev/null: Permission denied
autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4
sh: /dev/null: Permission denied
autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4
automake-1.15: error: autoconf failed with exit status: 1
ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $
But read about that, on:
Grsecurity Forums
NOTE: That is the link to this topic which I am now writing.
But rather (after I fixed the RBAC policy for the strange case):
- Code: Select all
ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $ ./autogen.sh
aclocal found
autoheader found
autoconf found
automake found
[Checks passed]
Generating...
configure.ac:41: installing './compile'
configure.ac:6: installing './config.guess'
configure.ac:6: installing './config.sub'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
dlib/Makefile.am: installing './depcomp'
ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $
But the autogen.sh wasn't too verbose, really.
...
That part only is of concern for grsec deployment.
How did I, as I write above, "fixed the RBAC policy for the strange case" and why I think it is strange (but of course, I could be wrong, I'm not an expert by any measure). And what were the exact denie lines in my logs?
This is what I saw in the /var/log/messages when I tried to run autogen.sh:
- Code: Select all
messages_150713_1051_gbn.log:Jul 13 10:51:33 gbn kernel: [401057.141950] grsec: (miro:U:/bin/bash) denied open of /dev/null for reading by /bin/bash[sh:29974] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:29973] uid/euid:1000/1000 gid/egid:1000/1000
Every time that I would try, I would get four of such messages exactly.
And, apparently, the only thing that "solved" this (I don't think, but I am no expert, so I could be wrong):
In the role:
- Code: Select all
# Role :miro
subject /bin/bash o {
...
/dev/null r
...
}
I changed that lline to:
- Code: Select all
/dev/null rw
Looking it up more closely. No. That is not strange. I see other lines reading and writing to /dev/null .
Sorry. All is fine here. (And I thought I had a strange issue.)
But I see other subjects in various roles reading and writing to /dev/null:
:egrep -B30 '\/dev\/null[[:space:]]{1,10}rw' /etc/grsec/policy | grep -B1 subject:
- Code: Select all
role default
subject /
--
# Role: default
subject /etc/cron.daily o {
--
# Role: default
subject /etc/cron.hourly o {
--
# Role: default
subject /etc/init.d o {
--
# Role: root
subject / {
--
# Role: root
subject /etc/cron.daily o {
--
# Role: root
subject /etc/cron.hourly o {
--
# Role: root
subject /etc/init.d o {
--
# Role: root
subject /sbin/agetty o {
--
# Role: root
subject /usr/libexec/dovecot/ssl-params o {
--
# Role: root
subject /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.4/cc1 o {
--
# Role: root
subject /usr/libexec/postfix o {
--
# Role: root
subject /usr/sbin/rkhunter o {
--
# Role: root
subject /usr/sbin/sshd o {
--
# Role: root
subject /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ar o {
--
# Role: root
subject /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/as o {
--
# Role: root
subject /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/ld o {
--
# Role: postfix
subject /usr/sbin/postsuper o {
--
# Role: miro
subject / {
--
# Role: miro
subject /usr/bin/sftp o {
--
# Role: miro
subject /usr/bin/ssh o {
--
# Role: miro
subject /usr/bin/git o {
--
# Role: miro
subject /usr/bin/vim o {
--
# Role: miro
subject /usr/bin/info o {
Sorry!