On 05/13/2015 11:57 AM, Datta, Souvik wrote: > Actually, I am considering the case where app X is vulnerable and it is > having a HTTP server embedded in it. Although app X and the process (which is > assigned domain : hm_phonebookaccess_app and owning the database with type - > hm_phonebookaccess_data_file) are having the same UID but they are running > as two different processes. > I have two questions here: > a) From my understanding of previous mail content, if app X tries to directly > do a raw access of the the database file owned by process having domain > hm_phonebookaccess_app - , it will be prevented by my policy. Is this > understanding correct? > b) However, if app X is running a http server then I have observed that it is > possible to access the database content through the http requests via the > http server. Can you please explain why this cannot be prevented by the > policy.
Database file access is subject to open/read/write permission checks between the source/subject domain and the target/object type, so as long as you do not allow the process domain to open/read/write the database file type, it won't be able to do that. In order to enforce access controls on AF_INET sockets beyond simple control of what operations you can invoke, you need to label the packets in some way and pass those labels with the packets through the network stack and, if the packet traverses the network, across the wire. That is not enabled by default as it isn't used in the common case and wasn't even supported in mainline Linux when SELinux was first merged. Over time, two primary forms of packet labeling and access controls have been integrated into SELinux: 1. SECMARK: A way to assign packet labels based on packet characteristics via iptables configuration, and then perform send/recv checks in policy between the sender/receiver domain and the packet type. Only enabled if you enable the corresponding support in your kernel and configure iptables SECMARK or CONNSECMARK rules. These packet labels are only propagated within the network stack and are not conveyed over the wire to other systems. 2. Labeled XFRM or NetLabel: Two mechanisms for labeling packets based on their sender, conveying the packet label across the wire to remote systems, and then performing recv checks in policy between the sender and receiver domains. The Labeled XFRM mechanism stores the packet label in an IPSEC security association and then infers the packet label from the SA on the receiving side; the NetLabel mechanism passes the packet label with each packet via an IP option (e.g. CIPSO). Only enabled if you enable the corresponding support in your kernel and configure xfrm or netlabel accordingly. These peer labels are propagated within the network stack and passed across the wire. It will be easier to enable and use SECMARK in Android as we have added the kernel configuration options to android-base.cfg and the iptables SECMARK support should already be included. For NetLabel, you would need to enable the kernel options and port netlabelctl to Android. Some resources: http://selinuxproject.org/page/NB_Networking http://paulmoore.livejournal.com/4281.html http://paulmoore.livejournal.com/7234.html _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
