From mboxrd@z Thu Jan  1 00:00:00 1970
From: Orion Poplawski <orion@nwra.com>
Subject: Re: Is auditing ftruncate useful?
Date: Wed, 12 Feb 2020 14:00:16 -0700
Message-ID: <27e13d2d-cc87-ce5f-557f-88474ce1d29f@nwra.com>
References: <5599a207-7054-af2e-6d10-0421154168b8@nwra.com>
	<8010cdd2-468b-ac87-54f1-2846baf28d28@nwra.com>
	<57c2b1a1-5406-4d77-9dc5-ad6c99b987a8@magitekltd.com>
	<1758232.KkKbY19U6n@x2>
	<17021a5a608.27df.85c95baa4474aabc7814e68940a78392@paul-moore.com>
	<CAHC9VhRhCQook8wPcYTb6Xfr0v+fqszzHxuVGzZxmK5N1KPzcw@mail.gmail.com>
	<4b16e97a-49d7-d558-0d87-7cdff23888b5@nwra.com>
	<CAHC9VhR-hGOgOkpQaFEM=CFCETR7goOxfYjT52brgUpNibnkBg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0389382517251315339=="
Return-path: <linux-audit-bounces@redhat.com>
Received: from mimecast-mx02.redhat.com
	(mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id F2C362093CFA
	for <linux-audit@redhat.com>; Wed, 12 Feb 2020 21:00:22 +0000 (UTC)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com
	[207.211.31.120])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9CA108E3897
	for <linux-audit@redhat.com>; Wed, 12 Feb 2020 21:00:22 +0000 (UTC)
In-Reply-To: <CAHC9VhR-hGOgOkpQaFEM=CFCETR7goOxfYjT52brgUpNibnkBg@mail.gmail.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
List-Id: linux-audit@redhat.com

This is a cryptographically signed message in MIME format.
--===============0389382517251315339==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
	micalg=sha-256; boundary="------------ms010701030209050402000704"

This is a cryptographically signed message in MIME format.
--------------ms010701030209050402000704
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/11/20 5:58 AM, Paul Moore wrote:
> On Mon, Feb 10, 2020 at 6:05 PM Orion Poplawski <orion@nwra.com> wrote:
>> On 2/10/20 3:54 PM, Paul Moore wrote:
>>> On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <paul@paul-moore.com> wrote:

>>>
>>> Generally speaking the only syscalls which generate a PATH record are
>>> those syscalls which take a file pathname as an argument.  The reason
>>> why is that pathnames are notoriously transient and are only valid for
>>> the instant they actually resolve to a file; in fact it is possible
>>> that by the time an open(2) syscall returns the fd to the calling
>>> application, the file it opened may no longer be accessible at the
>>> pathname used to open the file.  It really is that crazy.
>>>
>>> In the case of ftruncate(2) we see that the syscall doesn't take a
>>> pathname argument, it takes an open file descriptor, this is why you
>>> don't see a PATH record.  If we compare it to a syscall which does
>>> take a pathname, e.g. chown(2), we will generate a PATH record.  Take
>>> the example below where we use the example program found in the
>>> chown(2) manpage:
>>>
>>> # touch /tmp/test
>>> # auditctl -w /tmp/test -k path_test
>>> # gcc -o chown_test -g chown_test.c
>>> # ./chown_test
>>> ./chown_test <owner> <file>
>>> # ./chown_test nobody /tmp/test
>>> # ausearch -i -k path_test
>>> ----
>>> type=3DCONFIG_CHANGE msg=3Daudit(02/10/2020 17:50:45.251:255) : auid=3D=
root ses=3D5 subj
>>> =3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=3Dadd_rule =
key=3Dpath_test
>>> list=3Dexit res=3Dyes
>>> ----
>>> type=3DPROCTITLE msg=3Daudit(02/10/2020 17:51:29.356:258) : proctitle=
=3D./chown_test n
>>> obody /tmp/test
>>> type=3DPATH msg=3Daudit(02/10/2020 17:51:29.356:258) : item=3D0 name=3D=
/tmp/test inode=3D7
>>> 0660 dev=3D00:21 mode=3Dfile,644 ouid=3Droot ogid=3Droot rdev=3D00:00 o=
bj=3Dunconfined_u:obj
>>> ect_r:user_tmp_t:s0 nametype=3DNORMAL cap_fp=3Dnone cap_fi=3Dnone cap_f=
e=3D0 cap_fver=3D0
>>> cap_frootid=3D0
>>> type=3DCWD msg=3Daudit(02/10/2020 17:51:29.356:258) : cwd=3D/root/tmp
>>> type=3DSYSCALL msg=3Daudit(02/10/2020 17:51:29.356:258) : arch=3Dx86_64=
 syscall=3Dchown
>>> success=3Dyes exit=3D0 a0=3D0x7ffc820c0603 a1=3Dnobody a2=3Dunset a3=3D=
0x40044e items=3D1 ppid
>>> =3D1678 pid=3D35451 auid=3Droot uid=3Droot gid=3Droot euid=3Droot suid=
=3Droot fsuid=3Droot egid=3D
>>> root sgid=3Droot fsgid=3Droot tty=3Dpts1 ses=3D5 comm=3Dchown_test exe=
=3D/root/tmp/chown_tes
>>> t subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3Dpa=
th_test
>>>
>>> ... in the example above we see that we do have a PATH record, as expec=
ted.
>>>
>>
>> So, this is all reasonable.  But why do I get this with fchown which als=
o
>> takes a file descriptor?
>>
>> type=3DPROCTITLE msg=3Daudit(02/06/2020 10:59:30.562:59894) : proctitle=
=3Dkwin
>> -session 106f726361000123384967700000029380000_1548775895_794186
>> type=3DPATH msg=3Daudit(02/06/2020 10:59:30.562:59894) : item=3D0 name=
=3D(null)
>> inode=3D595335 dev=3Dfd:01 mode=3Dfile,600 ouid=3DUSER ogid=3DUSER rdev=
=3D00:00
>> obj=3Dunconfined_u:object_r:config_home_t:s0 objtype=3DNORMAL cap_fp=3Dn=
one
>> cap_fi=3Dnone cap_fe=3D0 cap_fver=3D0
>> type=3DSYSCALL msg=3Daudit(02/06/2020 10:59:30.562:59894) : arch=3Dx86_6=
4
>> syscall=3Dfchown success=3Dyes exit=3D0 a0=3D0xd a1=3D0x584b a2=3D0x584b=
 a3=3D0xc items=3D1
>> ppid=3D27089 pid=3D27152 auid=3DUSER uid=3DUSER gid=3DUSER euid=3DUSER s=
uid=3DUSER
>> fsuid=3DUSER egid=3DUSER sgid=3DUSER fsgid=3DUSER tty=3D(none) ses=3D16 =
comm=3Dkwin
>> exe=3D/usr/bin/kwin subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:=
c0.c1023
>> key=3Dperm_mod
>>
>> It's this disparity between fchown and ftruncate that caught my attentio=
n.
>=20
> First off, it is worth distinguishing between a PATH record with a
> valid pathname (the chown(2) case) and a PATH record with an
> invalid/NULL pathname (the fchown(2) case).  At this point you
> hopefully understand why those PATH records are different, and why
> they sometimes have a pathname, and why sometimes they do not.
>=20
> For syscalls which resolve pathnames the pathname information for the
> PATH records are collected as the pathname is resolved (the only time
> they are valid).  When the syscall is done, the resolved pathname
> information is turned into the PATH records you see.
>=20
> In the case of fchown(2) there is no pathname resolution, the kernel's
> fchown(2) implementation explicitly records the passed file descriptor
> for reasons that Casey mentioned: it's security relevant since you are
> changing the file's ownership.  The ftruncate(2) syscall isn't
> security relevant so there is no explicit attempt to record the file
> descriptor information.  This is why fchown(2) generates a pathless
> PATH record, and why ftruncate(2) does not.
>=20
> If you are still curious, I would suggest you take a look at the
> kernel code, all the answers are there, and we could always use
> another set of hands/eyes ;)

Thank you again for the detailed response.  I was working with RHEL7 stig
rules like:

https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/findi=
ng/V-72133

which seem to imply some security relevance for ftruncate, and then noticin=
g
that the ftruncate record didn't seem to provide any kind of useful
information at all.  But I can appreciate some cargo-cult like behavior in =
the
security implementation realm :).


--=20
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


--------------ms010701030209050402000704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCjYw
ggTpMIID0aADAgECAgRMDow4MA0GCSqGSIb3DQEBBQUAMIG0MRQwEgYDVQQKEwtFbnRydXN0Lm5l
dDFAMD4GA1UECxQ3d3d3LmVudHJ1c3QubmV0L0NQU18yMDQ4IGluY29ycC4gYnkgcmVmLiAobGlt
aXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDEzMDEGA1UE
AxMqRW50cnVzdC5uZXQgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKDIwNDgpMB4XDTExMTExMTE1
MzgzNFoXDTIxMTExMjAwMTczNFowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJ
bmMuMTkwNwYDVQQLEzB3d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBieSByZWZl
cmVuY2UxHzAdBgNVBAsTFihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVudHJ1c3Qg
Q2xhc3MgMiBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEMo1C0J4Z
nVuQWhBMtRAAIbkHSN6uboDW/xRQBuh1r2tGjuelT63DjLD6e+AZkf3wY61xSfOoHB+rNBkgTktU
6QCTvnAIMd6JU6xXvCTvKo9C1PfqlSVdFHbSzacS+huytFxhQL1f3VebRFXYxYkZPGU9uejUpS3C
LNPqgzGiCDxeWa4SLioKjF7zszGuCq1+7LBJCfynLiIeaGQ0nRbjpj0DMUAW95T2Sxk0yZfmIpxI
3mSggwtYBZjEIkaJBf2jvvZJTGEDFqT4Cpkc4sDGfmkCMleQA68AlKG53M6v7/R8GM4wC8qH+NVf
H1lR2IsLuTjGWMJTfNom1NvyvZDNAgMBAAGjggEOMIIBCjAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T
AQH/BAgwBgEB/wIBADAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmVu
dHJ1c3QubmV0MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvMjA0OGNh
LmNybDA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5lbnRydXN0
Lm5ldC9ycGEwHQYDVR0OBBYEFAmRpbrp8i4qdd/Nfv53yvLea5skMB8GA1UdIwQYMBaAFFXkgdER
gL7YibkIozH5oSQJFrlwMA0GCSqGSIb3DQEBBQUAA4IBAQAKibWxMzkQsSwJee7zG22odkq0w3jj
5/8nYTTMSuzYgu4fY0rhfUV6REaqVsaATN/IdQmcYSHZPk3LoBr0kYolpXptG7lnGT8lM9RBH2E/
GCKTyD73w+kP51j0nh9O45/h1d83uvyx7YA2ZmaFJlditeJusIJq0KwjE9EXFUYJWXbOp3CniB5x
Jz4d3tnqnQiKfyuW8oubFH/KRXJPCi1bv865e+iMiEyP114JkKDnyPmAPq3BMrJGw/3NDAzlwv1P
CbeCIJK802SfBzFN9s81aTek70c/JSt7Dt+bO7JxPSfOlC57Jq1InwR/nxuHzHodsSCQFQiuAhHT
wwA9qOtHMIIFRTCCBC2gAwIBAgIQF5XJg+ffrZoAAAAATDX/LTANBgkqhkiG9w0BAQsFADCBpTEL
MAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAg
RW50cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAyIENsaWVudCBDQTAeFw0xNzEy
MTUxNzE3MTBaFw0yMDEyMTUxNzQ3MDBaMIGTMQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGlu
Z3RvbjEQMA4GA1UEBxMHUmVkbW9uZDEmMCQGA1UEChMdTm9ydGhXZXN0IFJlc2VhcmNoIEFzc29j
aWF0ZXMxNTAWBgNVBAMTD09yaW9uIFBvcGxhd3NraTAbBgkqhkiG9w0BCQEWDm9yaW9uQG53cmEu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAop24yyNf/vYlUdWtgHFHWcittcBF
eMIWS5GJxcDDYSjYfHUYhiEq8D4eMrktwirxZqnGTwMdN+RCqrnNZSR/YOsHSwpsW+9eOtAAlHMP
CbaPsS+X0xxZX3VRSdxXulwELCE6Saik1UMQ0MWHts1TwNuDrAXlvmoxCHgXSgcs4ukfNSOAs49O
l09tOt5xI5NACz2sDjAiwonIm2ccuqbc5zJZiL2YOVTzOq9Aa/i38tRldTYkJH80WgnpmMZTSgGL
ua8kwA/u4Lmax2VEcoRMw9zzmJav8gFNpQDbVnO3Ik2nlreJ/FX9+JmUa7zDn4FS0rT37ZJ7rOA3
N968CwBHAwIDAQABo4IBfzCCAXswDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDBCBgNVHSAEOzA5MDcGC2CGSAGG+mwKAQQCMCgwJgYIKwYBBQUHAgEWGmh0dHA6
Ly93d3cuZW50cnVzdC5uZXQvcnBhMGoGCCsGAQUFBwEBBF4wXDAjBggrBgEFBQcwAYYXaHR0cDov
L29jc3AuZW50cnVzdC5uZXQwNQYIKwYBBQUHMAKGKWh0dHA6Ly9haWEuZW50cnVzdC5uZXQvMjA0
OGNsYXNzMnNoYTIuY2VyMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwuZW50cnVzdC5uZXQv
Y2xhc3MyY2EuY3JsMBkGA1UdEQQSMBCBDm9yaW9uQG53cmEuY29tMB8GA1UdIwQYMBaAFAmRpbrp
8i4qdd/Nfv53yvLea5skMB0GA1UdDgQWBBSU5GXZh96BMn8UDBnIwT0CYlbijTAJBgNVHRMEAjAA
MA0GCSqGSIb3DQEBCwUAA4IBAQAj5E9g5NtdnH5bR1qKtyUGL9Rd6BIZBrVIMoEkpXi6rRwhfeAV
2cU5T/Te94+pv5JkBQfJQAakeQM+VRvSHtODHTPot12IpX/Dm9oxhKXpWIveNjC/6Qbx+/E6iNvU
GTtTTtCfwwpmyzVpUnJUN0B9XSHy78+fjJkDUIv6byrBSC/zW0MxSd0HKtr2Do3FYZgEmFiEchDz
wJeTmpJiJN/IVk/gtfJXSYQFOA0QawovCSvGgZy/0fRY5y8h1MDWmVBRrHBRoL+ot9Q6nbhMyszv
EGIVYVvWleE3Zcpu0teQ5WDv7WYs6ZZexIkGhIIW65NWIa1rG+UYok993UqK2FGnMYIEXzCCBFsC
AQEwgbowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMTkwNwYDVQQLEzB3
d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBieSByZWZlcmVuY2UxHzAdBgNVBAsT
FihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVudHJ1c3QgQ2xhc3MgMiBDbGllbnQg
Q0ECEBeVyYPn362aAAAAAEw1/y0wDQYJYIZIAWUDBAIBBQCgggJ1MBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIxMjIxMDAxN1owLwYJKoZIhvcNAQkEMSIEIOC6
qt7buQkhrvg6lMFP1Yi7qXudab9J41nOVZjs7WIVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD
BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcsGCSsGAQQBgjcQBDGBvTCBujCBpTELMAkGA1UE
BhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0Lm5ldC9D
UFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAgRW50cnVz
dCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAyIENsaWVudCBDQQIQF5XJg+ffrZoAAAAA
TDX/LTCBzQYLKoZIhvcNAQkQAgsxgb2ggbowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRy
dXN0LCBJbmMuMTkwNwYDVQQLEzB3d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UxHzAdBgNVBAsTFihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVu
dHJ1c3QgQ2xhc3MgMiBDbGllbnQgQ0ECEBeVyYPn362aAAAAAEw1/y0wDQYJKoZIhvcNAQEBBQAE
ggEACCEplAkOPhB6KdDEbUeys66W37icrJnFSFmKn5NKFTs1wO+Wq2PkMGRVFTUHc5nht8yRm17W
ZSVFBMfoutZdBJcB69G6CbBYcp5xuW+IXiRheH9/3HpeYKQY+EVgjxUMr+trxHUb1iAA5Vw1JDio
ZDp//fVq9yEV8Yug8oTZnNLCevhxxXJrtdvhfbPIhyj+zYstVZ7ckIrSAKWH3k2Sa3PGomlcdEK/
tj3klxSkrzW9USyULmqM9n+4H1Oy7zt7p7AsDqhsJJO673ZxtHoV5ER6mjYGdkDV/mW1pOwBlso2
zsxIsC3LSB9C2xcc3PyPS0l80IwUpCzKQ2xcBhdTlAAAAAAAAA==
--------------ms010701030209050402000704--


--===============0389382517251315339==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============0389382517251315339==--