Date: Sun, 14 May 2006 20:38:33 +0800 From: "=?GB2312?B?ssy8ztPC?=" <millerfor@gmail.com> To: trustedbsd-discuss@freebsd.org Subject: Re: Using modified db_trace_self to show MAC Framework's denial information Message-ID: <d032e8510605140538s6300d5b3m3a107fc4849026d9@mail.gmail.com> In-Reply-To: <d032e8510605140535m49feb091v6ddd7a33900b96a3@mail.gmail.com> References: <000001c6736f$409db800$26024dd2@n610c> <005401c67377$cf93a4e0$1c00a8c0@panxj> <20060510174147.254cc82f.zhouyi04@ios.cn> <d032e8510605140535m49feb091v6ddd7a33900b96a3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I faced a difficulty!
I want all inode access information, so I used the same method as db_trace
to trace through td_frame ...
After several days testing, I found that the arguments passed into syscall
may be changed throughout running, below is my result:
#### I reserved a copy in thread sructure through bcopy like ktrace_syscall
if (params !=3D NULL && narg !=3D 0)
bcopy((const void*)args, (void *)(td->syscall_args), /* int
syscall_args[8] in sys/proc.h*/
(u_int)(narg * sizeof(int)));
#### in my own trace function:
void print_syscall_details(struct thread * td){
char * path =3D (char *)td->syscall_args[0];
swtich(td->td_frame->tf_eax)
case open:
....
}
the result is that open stat and etc syscalls can print out right file path=
,
However execve() not always
from ddb information it seems that the memory allocated for containing the
path has been removed causing to page fault
trace to execve() source code I found that this syscall will invoke
execve_copyin_args(...) allocating enough memory and copying the string in
trace open() not find such kind copyin action!!!!!!! it just make
nameidata->ni_dirp point to user space address
I do not know whether freebsd scheduler allows proc kernel code(syscall)
parallel running with user space code??????
2006/5/10, zhouyi zhou <zhouyi04@ios.cn>:
> Dear Colleques,
> TrustedBSD's MAC Framework lacks enough denial information in access
> control.
> For example, in SEBSD's avc deny information, only inode number was shown
> for an
> ordinary file access. This is due to the structure of UFS (which lack
> d_entry as
> ext2fs do).
> I suggest modifying ddb's db_trace_self facility to show vnode's
> corresponding
> path name.
> Take kern_stat for example:
> db_print_stack_entry_modified_by_ZhouyiZhou(name, narg, argnp, argp,
> callpc)
> const char *name;
> int narg;
> char **argnp;
> int *argp;
> db_addr_t callpc;
> {
> if (!strcmp(name,"kern_stat")){
> db_printf("%s: ", name);
> int i =3D 1;
> while (narg) {
> if (i =3D=3D 1)
> db_printf("executable =3D %s ",((struct thread *)
> db_get_value((int)argp, 4, FALSE))->td_proc->p_comm);
> if (i =3D=3D 2)
> db_printf("path =3D %s ",((char *) db_get_value((int)argp, 4,
> FALSE)));
> argp++;
> i++;
> --narg;
>
> }
> db_printf("\n");
> return;
> }
> return;
> }
> You can implement many others such as kern_open to print the pathname o=
f
> the access denied inode.
>
> This may not be the best soluation, but it is indeed a solution.
>
> Sincerely yours
> Zhouyi Zhou
>
> _______________________________________________
> trustedbsd-discuss@FreeBSD.org mailing list
> http://lists.freebsd.org/mailman/listinfo/trustedbsd-discuss
> To unsubscribe, send any mail to "
> trustedbsd-discuss-unsubscribe@FreeBSD.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d032e8510605140538s6300d5b3m3a107fc4849026d9>