Unfortunately, accessing to the protected files is done behind the scene and not part of the service interface. Thus, the client can't pass the file descriptor to the server.
Tai From: Nick Kralevich <[email protected]<mailto:[email protected]>> Date: Monday, October 7, 2013 8:04 PM To: Tai Nguyen <[email protected]<mailto:[email protected]>> Cc: Stephen Smalley <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Rules to access /proc/pid/cmdline The client ("A") should just pass a file descriptor to the other process ("B"). -- Nick On Mon, Oct 7, 2013 at 5:02 PM, Tai Nguyen (tainguye) <[email protected]<mailto:[email protected]>> wrote: Let's say we have a daemon that uses data from /proc to serve its clients. So, when a client connects to the daemon, the daemon queries the client data from /proc/pid and perform the services for the client. So, in this case, the daemon doesn't need to access all the (private) data file of the client; it just need to access the /proc data of the client. So, if I generalize the problem then the problem statement would be something like Let's say process A has some private files and some protected files. How do I give another process, process B, access to process A's protected files but not its private files. Thanks, Tai From: Nick Kralevich <[email protected]<mailto:[email protected]>> Date: Monday, October 7, 2013 6:48 PM To: Tai Nguyen <[email protected]<mailto:[email protected]>> Cc: Stephen Smalley <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Rules to access /proc/pid/cmdline What are you trying to do? Can you explain your use case? -- Nick On Mon, Oct 7, 2013 at 1:45 PM, Tai Nguyen (tainguye) <[email protected]<mailto:[email protected]>> wrote: I don't want to give server access to all client files (e.g., client private files); I just want to give server access to client's proc files. Tai On 10/7/13 4:32 PM, "Stephen Smalley" <[email protected]<mailto:[email protected]>> wrote: >On 10/07/2013 04:18 PM, Tai Nguyen (tainguye) wrote: >> Using domain can restrict access to system_data_file, but it still give >> access to processes' private files. >> Is there a way to tag an attribute to all /proc files that I can use >> instead of domain? > >If you want to restrict the server to only specific client domains, then >as I said before, define a macro that you use to allow the client to >connect to the server domain and as part of that macro assign a new >attribute to all of the client domains that you can use in an allow rule. > >For example, in te_macros, you can add: >define(`client_domain', ` >typeattribute $1 clientdomain; ># any allow rules needed to connect to the server >') > >And in attributes, you can add: >attribute clientdomain; > >Then in each client domain's .te file, you can add: >client_domain(<insert-name-of-client-domain-here>) > >And in the server's .te file, you can add: >r_dir_file(<insert-name-of-server-domain>, clientdomain) > >Then your server can only read /proc/pid files of its clients, not of >all domains. > >If you are worried about being able to read files under /proc/pid other >than /proc/pid/cmdline even for the client domains, then note that >private information files are often already gated by an additional >ptrace check, so if the server is not allowed ptrace permission to the >client domain, it won't be able to read those files even with the allow >rule above. But no, you can't currently label different files under >/proc/pid with different labels; they all get the domain of the >associated process presently and there isn't a way to change that >without a kernel change. > > > -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected]<mailto:[email protected]> with the words "unsubscribe seandroid-list" without quotes as the message. -- Nick Kralevich | Android Security | [email protected]<mailto:[email protected]> | 650.214.4037<tel:650.214.4037> -- Nick Kralevich | Android Security | [email protected]<mailto:[email protected]> | 650.214.4037
