From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Wed, 4 Jan 2017 08:58:02 +0700 Message-ID: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1389972601650301113==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kees Cook , Paul Moore Cc: linux-audit@redhat.com, Will Drewry , LKML , Andy Lutomirski List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1389972601650301113== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="856RwTMNQ5DxXgt1Csub3sfRTx5su8XLQ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --856RwTMNQ5DxXgt1Csub3sfRTx5su8XLQ Content-Type: multipart/mixed; boundary="HVPBPlEkBJcmfj8BVpTwNssF4Oaam5Jpd"; protected-headers="v1" From: Tyler Hicks To: Kees Cook , Paul Moore Cc: Eric Paris , Andy Lutomirski , Will Drewry , linux-audit@redhat.com, LKML Message-ID: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> In-Reply-To: --HVPBPlEkBJcmfj8BVpTwNssF4Oaam5Jpd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/04/2017 04:44 AM, Kees Cook wrote: > On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore wrote:= >> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook wrot= e: >>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore wrot= e: >>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook wr= ote: >>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore w= rote: >>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook = wrote: >>>>>>> I still wonder, though, isn't there a way to use auditctl to get = all >>>>>>> the seccomp messages you need? >>>>>> >>>>>> Not all of the seccomp actions are currently logged, that's one of= the >>>>>> problems (and the biggest at the moment). >>>>> >>>>> Well... sort of. It all gets passed around, but the logic isn't ver= y >>>>> obvious (or at least I always have to go look it up). >>>> >>>> Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at >>>> least one other action, but I can't remember which off the top of my= >>>> head)? >>> >>> Sure, but if you're using audit, you don't need RET_ALLOW to be logge= d >>> because you'll get a full syscall log entry. Logging RET_ALLOW is >>> redundant and provides no new information, it seems to me. >> >> I only bring this up as it might be a way to help solve the >> SECCOMP_RET_AUDIT problem that Tyler mentioned. >=20 > So, I guess I want to understand why something like this doesn't work, > with no changes at all to the kernel: >=20 > Imaginary "seccomp-audit.c": >=20 > ... > pid =3D fork(); > if (pid) { > char cmd[80]; >=20 > sprintf(cmd, "auditctl -a always,exit -S all -F pid=3D%d", pid)= ; > system(cmd); > release... > } else { > wait for release... > execv(argv[1], argv + 1); > } > ... >=20 > This should dump all syscalls (both RET_ALLOW and RET_ERRNO), as well > as all seccomp actions of any kind. (Down side is the need for root to > launch auditctl...) Hey Kees - Thanks for the suggestion! Here are some of the reasons that it doesn't quite work: 1) We don't install/run auditd by default and would continue to prefer not to in some situations where resources are tight. 2) We block a relatively small number of syscalls as compared to what are allowed so auditing all syscalls is a really heavyweight solution. That could be fixed with a better -S argument, though. 3) We sometimes only block certain arguments for a given syscall and auditing all instances of the syscall could still be a heavyweight soluti= on. 4) If the application spawns children processes, that rule doesn't audit their syscalls. That can be fixed with ppid=3D%d but then grandchildren pids are a problem. 5) Cleanup of the audit rule for an old pid, before the pid is reused, could be difficult. Tyler >=20 > Perhaps an improvement to this could be enabling audit when seccomp > syscall is seen? I can't tell if auditctl already has something to do > this ("start auditing this process and all children when syscall X is > performed"). >=20 > -Kees >=20 --HVPBPlEkBJcmfj8BVpTwNssF4Oaam5Jpd-- --856RwTMNQ5DxXgt1Csub3sfRTx5su8XLQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbFaqAAoJENaSAD2qAscKH84QAKDIRlDLanPpwHFdiAh9O1Rs PjHzq/Cctmex7CcrPfaESvuqIhs+YvQHqx6VOjD5HcjZRCQKJ/vdWiUhXdsyzrIi cEUPxUsA9YwRmfcFd4XQSkJM4OpaznLmhZsksMtmhNdwkncmuwUKRCw0xfulAw5H IQODQR2WIEFNIdllfCf85qz9dMZtB4N6G/GaJ9iPSa5xm317dmNac8l0YZlsCqfF DkKj0ZZtwYXJ2VG/PCoJkmEc/AmVZdAyU8NJiXg2n7ACmjNPmOsKhLdKfFCwUyrB 9lGIJdtBFfqS7PgzoATKyFbaLNJf5+qwzLl1kXFhDsNCKze3SXg9BsUZUDvflm1w z4X2a/WECxYSBhEogacTdLNx3TkujGNuUicqBYHgIGnPPdPNxr5/gVBaMc2qLaNB JXuWNGSG028GBAbQkOepid3Lwmz+gvJXpuBsntiLVNSnaBWo3WA5kOKMpBEkIYpW uGIfx+2xZqZk//bCNsLYuGaLcqeuNFc5qUoQztGxSnmn0ePxh1vbIeq5JZniA8L2 IL9Qw9Fxh1IrjaTfNIZL9WkRtsnZFrgFpd+0ADlii7iq5erqJhp8ga/cBkk6bT8c txv8sLnnRI/t+zxwu7TX8WdcoGqA+H7Q/fC8J9MZF7dw39P7Onbn7dVli2cn8QOD ncsbAwMXOIFFq52iOf54 =lmM2 -----END PGP SIGNATURE----- --856RwTMNQ5DxXgt1Csub3sfRTx5su8XLQ-- --===============1389972601650301113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1389972601650301113==--