From: russell@coker.com.au (Russell Coker) Date: Wed, 22 Mar 2017 01:44:58 +1100 Subject: [refpolicy] sshd capability net_admin In-Reply-To: References: <11554005.jzciKoBjkI@russell.coker.com.au> Message-ID: <3893509.LLB6BINqIJ@russell.coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com OK, ausearch says that it's SO_SNDBUFFORCE. Thanks for the pointer about ausearch, I obviously need to spend some time investigating tools that were invented after I developed my work practices. SO_SNDBUFFORCE (since Linux 2.6.14) Using this socket option, a privileged (CAP_NET_ADMIN) process can perform the same task as SO_SNDBUF, but the wmem_max limit can be overridden. socket(7) has the above, so it seems that dontaudit will do. On Tuesday, 21 March 2017 3:03:35 PM AEDT cgzones wrote: > I like to use the -i flag of ausearch to interpret the syscalls for me. > Are you sure with the value of 20? I think it's hexadecimal, which > translates to 32 SO_SNDBUFFORCE, which might get used via libpam-systemd in > systems libraries. > > On 21 Mar 2017 12:00 pm, "Russell Coker via refpolicy" < > refpolicy at oss.tresys.com> wrote: > > /* Allow interface configuration */ > /* Allow administration of IP firewall, masquerading and accounting */ > /* Allow setting debug option on sockets */ > /* Allow modification of routing tables */ > /* Allow setting arbitrary process / process group ownership on > sockets */ > /* Allow binding to any address for transparent proxying (also via NET_RAW) > */ > /* Allow setting TOS (type of service) */ > /* Allow setting promiscuous mode */ > /* Allow clearing driver statistics */ > /* Allow multicasting */ > /* Allow read/write of device-specific registers */ > /* Allow activation of ATM control sockets */ > > Above is the CAP_NET_ADMIN description from /usr/include/linux/capability.h. > > type=AVC msg=audit(1490092328.100:101): avc: denied { net_admin } for > pid=666 comm="sshd" capability=12 scontext=system_u:system_r:sshd_t:s0- > s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > tclass=capability > permissive=0 > type=SYSCALL msg=audit(1490092328.100:101): arch=c000003e syscall=54 > success=no exit=-1 a0=5 a1=1 a2=20 a3=7ffc7051bd00 items=0 ppid=1 pid=666 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) > > Above are the audit.log entries from sshd requesting net_admin access. From > the strace source it seems that syscall 54 on AMD64 is setsockopt(), a0 > would > be the socket handle, a1 is the level and /usr/include/asm-generic/socket.h > defines SOL_SOCKET as 1, and SO_RCVTIMEO as 20. > > But a grep of the sshd source doesn't show it using SO_RCVTIMEO as the > optname > for setsockopt(). Am I making a mistake in reading the audit.log? > > We probably want a dontaudit rule, but I'm trying to work out exactly what > sshd is trying to do first. Any suggestions? > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/