On Wed, 2013-01-30 at 01:14 +0100, Andrew Jones wrote: > On Tue, 2013-01-29 at 10:07 -0500, m.roth@xxxxxxxxx wrote: > > Andrew Jones wrote: > > > (Apologies in advance for the length of this mail. I am a total noob at > > > SELinux so my vocabulary is probably not correct. Hopefully you will be > > > able to understand from context what I am trying to say.) > > > > > > I have been setting up x11vnc on some of my machines. It looks like > > > there are a hundred different ways of setting it up but I have chosen to > > > follow the spirit of this entry in the Fedora Forum: > > > > > > http://forums.fedoraforum.org/showpost.php?p=1448696&postcount=2 > > > > > > This works with SELinux permissive but fails completely when enforcing. > > > > > > Even when running permissively there are so many SELinux events in the > > > first few seconds that many are dropped as shown here: > > > > > > Jan 29 03:44:10 ecafe audispd: queue is full - dropping event > > > > > > After several hours of scouring the system log, running sealert and > > > creating policies, rinsing and repeating I think I have generated the > > > command line that will identify all the events which occur during an > > > x11vnc session: > > > > > > egrep ps\|x11vnc\|tcpd\|mission-control /var/log/audit/audit.log | > > > audit2allow -M mypol > > > > > > By repetitively running that line, applying the generated policy then > > > restarting the computer and launching a new vnc session eventually all > > > the events are able to be recorded without filling the queue. > > > > > Andrew, > > > > First of all, how did you install x11vnc? Did you use yum, or is this > > from a tarball. You should ALWAYS prefer yum install, since this will > > get all dependencies, and install policy as part of the package. > > Installed from yum. > Having read the x11vnc man page I got the impression it's a bit of a > swiss army knife and I had *assumed* that as it was so hard to predict > how it would be used it would not make sense to enforce any particular > policy. Is there a way of extracting and examining the policies in an > rpm? > > > > > Secondly, you should be looking at what it wants to do. For example, > > the fact that mcelog is in there worries me, a *lot*, since mcelog > > records ->hardware errors<-, meaning that you could be having hardware > > issues. > > > It is necessary for x11vnc to discover the name of an X11 authorization > file and the trick to do so is to do a `ps wwwaux | grep '/X.*-auth'` , > followed by a bit more grep and sed trickery to isolate the name of the > file that appears on the command line that launched xorg. > > The command above has this for output... > root 26003 0.4 1.1 24184 12120 tty9 Ss+ 12:34 > 2:46 /usr/bin/Xorg :0 -br -verbose -logverbose 7 > -auth /var/run/gdm/auth-for-gdm-xpIgEt/database -nolisten tcp > > ... and the sed and grep trickery isolates the string > '/var/run/gdm/auth-for-gdm-xpIgEt/database' > which is a required parameter for x11vnc > > It did seem that many, many of the AVCs were caused by ps trying to get > attributes of or open directories in /proc. > > Why have I told you all this? > > grep type=AVC audit.log.1 | grep mcelog | grep -v comm=\"ps\" has no > output > grep type=AVC audit.log.1 | grep mcelog has 21 lines of output > > So all the AVCs which mention mcelog include comm="ps" > Here is a typical sequence > type=AVC msg=audit(1359035800.677:1209): avc: denied { getattr } for > pid=2248 comm="ps" path="/proc/539" dev="proc" ino=14875 > scontext=system_u:system_r:tcpd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:mcelog_t:s0 tclass=dir > > type=AVC msg=audit(1359035800.677:1210): avc: denied { search } for > pid=2248 comm="ps" name="539" dev="proc" ino=14875 > scontext=system_u:system_r:tcpd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:mcelog_t:s0 tclass=dir > > type=AVC msg=audit(1359035800.677:1210): avc: denied { read } for > pid=2248 comm="ps" name="stat" dev="proc" ino=14058 > scontext=system_u:system_r:tcpd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:mcelog_t:s0 tclass=file > > type=AVC msg=audit(1359035800.677:1210): avc: denied { open } for > pid=2248 comm="ps" path="/proc/539/stat" dev="proc" ino=14058 > scontext=system_u:system_r:tcpd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:mcelog_t:s0 tclass=file > > There were just 3 /proc directories that prompted this sequence of AVCs > containing mcelog and these were 539 (shown above), 517 and 509, but > having rebooted since I don't now know what processes they correspond to > and I suspect many other AVCs may have been omitted due to queue > overflow. Audit.log currently contains 900 lines of AVCs related to ps > accessing the /proc directory Having checked the timestamps in the system log I see that each set of AVCs occurred just once between re-boots (I rebooted after every launch of vnc / generation of new policies) so they could all be referring to the same process. I also noted that on my Fedora 18 machines mcelog is running as a daemon: $ ps -A www | grep mcelog 528 ? Ss 0:00 /usr/sbin/mcelog --ignorenodev --daemon --foreground mcelog is not running as a daemon on my Fedora 16 machine ... So I could be easily persuaded that the AVCs which mention mcelog refer to the attempts of ps to access the mcelog process. > > I tried to replicate the generation of AVCs by running ps from a command > prompt but nothing happened. Could ps be running from the wrong > context? Can you tell I hadn't a clue what I was talking about when I > asked that question?? > > > > Third, read the man page for audit2allow. It tells you how to convert > > from text policy to compiled and install it. It's not complicated. > Thanks for that. > > > > > Fourth, the "dropped" indicates that there are so many errors the queue > > can't keep up. From an old closed bug, one note for this problem is: > > -b 8192 in auditd.conf > > priority_boost = 4 in auditd.conf > > priority_boost = 8 in audispd.conf > > q_depth = 2048 in audispd.conf > > Thanks also for that. > > > > mark > > > Andy > > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
