-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/30/2013 02:13 AM, Andrew Jones wrote: > 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 > Lets try this. chcon -t xserver_exec_t /usr/bin/x11vnc And create myvnc.te that looks like the following: cat myvnc.te #========================================================================== policy_module(myvnc,1.0) gen_require(` type xserver_exec_t, xserver_t; ') tcpd_wrapped_domain(xserver_t, xserver_exec_t) #======================================================================= make -f /usr/share/selinux/devel/Makefile myvnc.pp semodule -i myvpnc.pp Then try it again. The reason you are getting all the AVC's about random domains is the x11vnc is doing the equivalent of the ps command, it it is walking through /proc and looking at every process. The SELinux interface to handle this would have been: domain_read_all_domains_state(tcpd_t) But what we really want is tcpd_t to transition to xserver_t when running x11vnc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEJIUYACgkQrlYvE4MpobP2PQCgnAJUdKfoVY7mxFu4otzFEh3O ZI8An2WcO9laKMFbfhEhcvTctHXKQjU+ =dcVj -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
