From: aranea@aixah.de (Luis Ressel) Date: Sun, 18 Jun 2017 21:45:17 +0200 Subject: [refpolicy] [PATCH] netutils: Add some permissions required by nmap to traceroute_t In-Reply-To: <41966766-bcf8-5672-3adf-502f37f4dabe@ieee.org> References: <20170607160337.16186-1-aranea@aixah.de> <1a671542-b374-0b8b-3d34-dc1d2793f9fc@ieee.org> <20170608022636.1e787020@vega.skynet> <20170609035646.5abcfb5f@vega.skynet> <41966766-bcf8-5672-3adf-502f37f4dabe@ieee.org> Message-ID: <20170618214517.39628f5e@vega.skynet.aixah.de> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Mon, 12 Jun 2017 18:32:35 -0400 Chris PeBenito via refpolicy wrote: > On 06/08/2017 09:56 PM, Luis Ressel wrote: > > On Thu, 8 Jun 2017 18:15:16 -0400 > > Chris PeBenito wrote: > > > >>> Okay, I'll add a separate rule for self:socket, then. I'm curious, > >>> though: Why don't you want to use the :{ ... } syntax here? > >> > >> I find it harder to read. For example, I missed that you added the > >> socket class. What socket type is being used? Did you try > >> enabling policycap extended_socket_class (assuming kernel 4.11+ > >> and libsepol 2.7+)? > > > > Thanks for the hint; I wasn't aware of this new policycap. I tried > > enabling it, but I must've done something wrong: I upgraded libse*, > > checkpolicy and policycoreutils to the latest git HEAD, edited > > policy/policy_capabilities and recompiled the policy. Now seinfo > > --polcaps shows a new polcap "redhat1", but the denial in the audit > > logs still reports the class as "socket". > > > > (I didn't upgrade setools, but those don't have anything to do with > > the policy compilation, right? And before you ask, yes, I am on > > linux 4.11, 4.11.3 to be exact). > >extended_socket_class > > Any ideas? I'll have another look at this during the weekend. > > You need to recompile SETools, as it is statically linked to libsepol. I recompiled SETools in the meantime; seinfo --polcap now properly reports the extended_socket_class capability. However, the avc denail message still reports tclass=socket. The full denial message, as reported by ausearch, is ---- type=PROCTITLE msg=audit(06/18/2017 21:34:45.744:1043) : proctitle=/usr/bin/nmap -sn 192.168.2.1 type=SYSCALL msg=audit(06/18/2017 21:34:45.744:1043) : arch=x86_64 syscall=socket success=no exit=EACCES(Permission denied) a0=local a1=SOCK_RAW a2=ip a3=0x311 items=0 ppid=18173 pid=18174 auid=lre uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=nmap exe=/usr/bin/nmap subj=staff_u:sysadm_r:traceroute_t key=(null) type=AVC msg=audit(06/18/2017 21:34:45.744:1043) : avc: denied { create } for pid=18174 comm=nmap scontext=staff_u:sysadm_r:traceroute_t tcontext=staff_u:sysadm_r:traceroute_t tclass=socket permissive=0 ---- Doesn't this mean the proper class should be rawip_socket? traceroute_t already has the create permission for this class. At this point, I'm inclined to just add the ":socket create" permission, but I'm still interested if anyone has an idea why it is needed. Regards, Luis Ressel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170618/ff50fbe5/attachment.bin