From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Not seeing access denied audit messages in restricted subdirectories Date: Sun, 10 Nov 2019 16:48:02 +0100 Message-ID: <20191110164802.456804a5@ivy-bridge> References: <20191108223905.773a79d3@ivy-bridge> <4f152216-63dc-4785-d878-fc57f48217f0@magitekltd.com> <20191109110841.7760c408@ivy-bridge> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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: John T Olson Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, On Sat, 9 Nov 2019 21:58:33 -0700 "John T Olson" wrote: > If I were to officially request this type of functionality from the > kernel team (throw an event even without a valid path), how would I > do that? Just file an issue here: https://github.com/linux-audit/audit-kernel/issues -Steve > From:=09Steve Grubb > To:=09Lenny Bruzenak > Cc:=09linux-audit@redhat.com > Date:=0911/09/2019 03:09 AM > Subject:=09[EXTERNAL] Re: Not seeing access denied audit > messages in restricted=09subdirectories > Sent by:=09linux-audit-bounces@redhat.com >=20 >=20 >=20 > On Sat, 9 Nov 2019 20:18:45 +1100 > Lenny Bruzenak wrote: > > On 11/9/19 8:39 AM, Steve Grubb wrote: > > =20 > > > On Fri, 8 Nov 2019 13:39:58 -0700 > > > "John T Olson" wrote: > > > =20 > > >> Greetings, > > >> > > >> I have the following 2 audit rules set up: > > >> > > >> -a always,exit -F arch=3Db64 -S all -F exit=3D-EACCES -F > > >> dir=3D/gpfs/fs1 -a always,exit -F arch=3Db64 -S all -F exit=3D-EPERM > > >> -F dir=3D/gpfs/fs1 > > >> > > >> I have a directory structure like the following: > > >> > > >> (13:15:26) zippleback-vm1:~ # ls -la /gpfs/fs1/test/ > > >> total 257 > > >> drwx------. 3 root root 4096 Nov 7 12:46 . > > >> drwxr-xr-x. 15 root root 262144 Nov 7 12:50 .. > > >> drwx------. 2 root root 4096 Nov 7 12:46 test2 > > >> > > >> Essentially, directory "/gpfs/fs1/test/" is owned by root and has > > >> permissions 700. The subdirectory underneath it (with > > >> path /gpfs/fs1/test/test2) is also owned by root and has > > >> permissions 700. > > >> > > >> When I have a non-root user attempt to list the contents of > > >> directory "/gpfs/fs1/test/" I receive an audit message for the > > >> denied access. However, when the non-root user attempts to list > > >> the contents of the subdirectory (/gpfs/fs1/test/test2), there is > > >> no audit message generated. Does anyone know why this is and how > > >> I get audit messages in both cases? =20 > > > Yes, the reason is because the path did not resolve so audit never > > > saw it. This has been this way for quite some time. In the past, > > > it was said because the path never resolved, a PATH record with > > > all attributes could not be generated. I have mentioned to kernel > > > maintainers, that the path is available as a syscall argument. > > > While a full PATH record cannot be generated with file attributes, > > > an abbreviated one could be generated. So, far...no one has saw > > > this as a big enough problem to fix. Personally, I think it should > > > be fixed. =20 > > At first blush, I completely agree. However, I'm wondering if the > > first attempt completely failed, how would the second one even have > > the knowledge of the unattainable path? =20 >=20 > Because it was an argument to the syscall. For example, if its the > open syscall, then arg0 points to the path. You cannot create a > completed PATH record because you have no device, inode, or mode. But > you do have the attempted path. >=20 >=20 > > In the real world if the first one failed (in this example > > /gpfs/fs1/test), because although the parent directory would list > > the test directory, it is not reachable. But the listing of that one > > would not happen at all (/gpfs/fs1/test/test2), because the non-root > > user had no access to the listing dir (/gpfs/fs1/test). The caller > > would have had to gain knowledge of its existence through other > > means. > > > > I wonder if even acknowledging its existence via a "denied access" > > event would be slightly counter-productive? The abbreviated PATH > > would be nice, and since it is there, sure, why not? Then, if all > > calls either to non-existent or say access-denied paths looked the > > same, then that would be fine I think. I would not be as happy if > > one could sniff out inaccessible directories (as opposed to > > non-existent) from audited events though. =20 >=20 > Only sysadmins have access to the audit trail. And I think you can > sniff out inaccessible directories with a little shell or python > scripting as a non-admin user. Of course doing so should cause some > metric to spike. >=20 > -Steve >=20 > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.redhat.com_mai= lman_listinfo_linux-2Daudit&d=3DDwIF-g&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DzKt0O= VPVj1IsYJ426vWytEm0W7ykoz5eLpKx1CRdg7g&m=3DuRWgnhi1IOG1-E_ehlnHOOsz0K6gqvbF= ZqAC4_Ehqdc&s=3DI6e27HAAnCtaHVdDbyeoAZVog0bJDsoIjeAYljnyH-U&e=3D >=20 >=20 >=20 >=20 >=20