From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Add a new record which shows when fcaps escalate permissions Date: Mon, 20 Oct 2008 07:24:15 -0400 Message-ID: <200810200724.16076.sgrubb@redhat.com> References: <1224364082.3189.88.camel@paris-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1224364082.3189.88.camel@paris-laptop> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Saturday 18 October 2008 17:08:02 Eric Paris wrote: > type=3DSYSCALL msg=3Daudit(1224363342.919:60): arch=3Dc000003e syscall=3D= 59 > success=3Dyes exit=3D0 a0=3D9f7460 a1=3D9fe7c0 a2=3Da059e0 a3=3D3445170= a70 items=3D2 > ppid=3D2328 pid=3D2356 auid=3D0 uid=3D500 gid=3D500 euid=3D500 suid=3D5= 00 fsuid=3D500 > egid=3D500 sgid=3D500 fsgid=3D500 tty=3Dpts0 ses=3D1 comm=3D"ping" exe=3D= "/bin/ping" > subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3D(nul= l) execve syscall record > type=3DEXECVE msg=3Daudit(1224363342.919:60): argc=3D2 a0=3D"ping" a1=3D= "127.0.0.1" > type=3DUNKNOWN[1321] msg=3Daudit(1224363342.919:60): > file_permitted=3D0000000000003000 file_inheritable=3D0000000000003000 > task_permitted=3D0000000000000000 task_inheritable=3D0000000000000000 > task_effective=3D0000000000000000 bprm_effective=3D0000000000003000=20 Good. I'd prefer the proc file system abbreviations to save disk space. > type=3DCWD msg=3Daudit(1224363342.919:60): =C2=A0cwd=3D"/home/test" > type=3DPATH msg=3Daudit(1224363342.919:60): item=3D0 name=3D"/bin/ping"= inode=3D49227 > dev=3Dfd:00 mode=3D0100755 ouid=3D0 ogid=3D0 rdev=3D00:00 > obj=3Dsystem_u:object_r:ping_exec_t:s0 cap_permitted=3D0000000000003000 > cap_inheritable=3D0000000000003000 type=3DPATH msg=3Daudit(1224363342.9= 19:60): > item=3D1 name=3D(null) inode=3D507963 dev=3Dfd:00 mode=3D0100755 ouid=3D= 0 ogid=3D0 > rdev=3D00:00 obj=3Dsystem_u:object_r:ld_so_t:s0 > > So here's an example of my new record which shows a process getting new > capabilities. What about capset/capget ? > Does this show the type of information you guys think would be useful? Yes, I think this is heading in the right direction. The capset syscall i= s the=20 one that we also need to see since that is the one that started the whole= =20 discussion.=20 Also, what does it look like when you run a normal setuid program? What d= oes=20 it look like when SE Linux denies a capability? -Steve