10:35 a.m.
On Thu, 2013-01-31 at 10:04 -0500, Daniel J Walsh wrote:
On 01/30/2013 08:11 PM, Andrew Jones wrote:
> On Wed, 2013-01-30 at 08:33 -0500, Daniel J Walsh wrote:
>> 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(a)5-cent.us 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(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>
>>>
>>> -- selinux mailing list selinux(a)lists.fedoraproject.org
>>> 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.
>>
>>
>>
> Thank you for that - the difference was phenomenal!
>
> At first it didn't seem to do anything because it was a bash script, not
> x11vnc, that was running ps. However, I read the x11vnc manual again and
> finally realized how to make it run ps for me.
>
> Once I had made the change the AVCs reduced from several hundred to a large
> handful.
>
> (Removing your myvnc.pol policy returned it to producing hundreds of AVCs
> again)
SNIP
Well I am happy it is working for you, but we prefer the solution to
get
tcpd_t to transition to xserver_t, when running x11vnc.
Which hopefully will be showing up in an update release.
Sorry I think I did not make myself clear. I removed your policy just
to see what a difference it made (HUGE), and then I re-applied it.
The policies I generated afterwards were for the things that weren't
already fixed by your policy.