On 06/26/2009 09:19 AM, Christopher J. PeBenito wrote:
On Thu, 2009-06-25 at 22:12 +0100, Paul Howarth wrote:
> On Thu, 25 Jun 2009 13:24:14 -0400
> "Christopher J. PeBenito"<cpebenito(a)tresys.com> wrote:
>
>> On Tue, 2009-06-23 at 16:11 +0100, Paul Howarth wrote:
>>> On Mon, 22 Jun 2009 10:37:10 +0100
>>> Paul Howarth<paul(a)city-fan.org> wrote:
>>>
>>>> On 22/06/09 07:58, Paul Howarth wrote:
>>>>> On Sun, 21 Jun 2009 01:49:01 +0530
>>>>> Rahul Sundaram<sundaram(a)fedoraproject.org> wrote:
>>>>>
>>>>>> On 06/20/2009 04:41 PM, Daniel J Walsh wrote:
>>>>>>> On 06/19/2009 05:54 AM, Rahul Sundaram wrote:
>>>>>>> Is it continuing to happen or was this a one time
>>>>>>> occurrence. The only code that I imagine opens and
>>>>>>> reads /selinux/mls is libselinux and this opens it, reads
the
>>>>>>> value and closes the file in the same function call, so it
>>>>>>> can not leak.
>>>>>> It happens everytime I connect to a CDMA network via
>>>>>> NetworkManager and run vpnc.
>>>>>>
>>>>>> Rahul
>>>>> I've just had a very similar denial, when starting openvpn via
>>>>> NetworkManager:
>>>>>
>>>>> type=AVC msg=audit(1245653684.772:27): avc: denied { read }
>>>>> for pidT86 comm="openvpn" name="mls"
dev=selinuxfs ino
>>>>> scontext=system_u:system_r:openvpn_t:s0
>>>>> tcontext=system_u:object_r:security_t:s0 tclass=file
>>>>> type=SYSCALL msg=audit(1245653684.772:27): archÀ00003e
>>>>> syscall=2 success=no exit=-13 a0ff5652e270 a1=0 a2ff5652e27c
>>>>> a3ÿfffff8 items=0 ppidT75 pidT86 auidB94967295 uid=0 gid=0
>>>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
>>>>> sesB94967295 comm="openvpn"
exe="/usr/sbin/openvpn"
>>>>> subj=system_u:system_r:openvpn_t:s0 key=(null)
>>>>>
>>>>> Didn't stop openvpn working.
>>>> Just got this one too, after running "rndc querylog" to turn
on
>>>> named's query logging from a root shell.
>>>>
>>>> type=AVC msg=audit(1245663191.793:115): avc: denied { read }
>>>> for pid!774 comm="rndc" name="mls" dev=selinuxfs
ino
>>>> scontext=unconfined_u:unconfined_r:ndc_t:s0-s0:c0.c1023
>>>> tcontext=system_u:object_r:security_t:s0 tclass=file
>>>> type=SYSCALL msg=audit(1245663191.793:115): archÀ00003e syscall=2
>>>> success=no exit=-13 a0ffa1a717d0 a1=0 a2ffa1a717dc a3ÿfffff8
>>>> items=0 ppid800 pid!774 auidP0 uid=0 gid=0 euid=0 suid=0
>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="rndc"
>>>> exe="/usr/sbin/rndc"
>>>> subj=unconfined_u:unconfined_r:ndc_t:s0-s0:c0.c1023 key=(null)
>>> /usr/sbin/rndc is linked against libselinux, which ties in with
>>> Stephen's explanation of the openvpn/vpnc issue too.
>>>
>>> I'm adding these to local policy for now:
>>>
>>> selinux_dontaudit_read_fs(ifconfig_t)
>>> selinux_dontaudit_read_fs(ndc_t)
>>> selinux_dontaudit_read_fs(openvpn_t)
>> In the long term, the more appropriate interface would be
>> seutil_dontaudit_libselinux_linked(), which is for programs that link
>> against libselinux for basic reasons, such as doing a setfilecon() or
>> setfscreatecon(), but don't use the features that depend on the
>> libselinux constructor.
> That makes sense for ifconfig_t and ndc_t that are actually linked
> against libselinux, but openvpn_t uses sysnet_exec_ifconfig so perhaps
> that interface now needs to add seutil_dontaudit_libselinux_linked()
> for its calling domain?
I think I can buy that, as long as there is a comment explaining why its
there.
Yes the problem is any confined domain that executes a bin_t or any tool
without a transition which loads libselinux will generate this avc.