Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?d032e8510605140538s6300d5b3m3a107fc4849026d9>