From: aranea@aixah.de (Luis Ressel) Date: Sun, 18 Jun 2017 22:50:43 +0200 Subject: [refpolicy] [PATCH] netutils: Add some permissions required by nmap to traceroute_t In-Reply-To: <20170618214517.39628f5e@vega.skynet.aixah.de> 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> <20170618214517.39628f5e@vega.skynet.aixah.de> Message-ID: <20170618225043.58fa4393@vega.skynet.aixah.de> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sun, 18 Jun 2017 21:45:17 +0200 Luis Ressel via refpolicy wrote: > 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. Nevermind, I figured this out. The "a2=ip" had misled me to believe rawip_socket would be the right class here, but in fact it only means that the third argument to socket() is zero. I'd missed "a0=local" (aka PF_UNIX). In other words, nmap is creating a raw *Unix domain socket* here (it doesn't actually use this socket, it just needs a random socket to get some info from the SIOCETHTOOL ioctl). The kernel's socket_type_to_security_class() doesn't care about this kind of socket (no matter if extended_socket_class is enabled or not), hence it assigns the "socket" class. 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/27adfefd/attachment.bin