Thanks for the clarification.
I will look into SECMARK.
Regards,
Souvik
________________________________________
From: [email protected] [[email protected]]
Sent: Wednesday, May 13, 2015 11:12 PM
To: Datta, Souvik
Cc: Stephen Smalley; [email protected]
Subject: RE: Assigning domain and type to platform application and its data
> Thanks Stephen for the links. I would look into SECMARK.
>
> One question: If I add a rule -
>
> neverallow netd hm_phonebookaccess_data_file : file { write read };
>
> what would be the impact of adding this rule.
That is ONLY a compile time check enforced by the sepolicy compiler
check_policy. This means their is no representation in the binary policy
that is loaded into the kernel.
The effect would be that any process in the netd domain, which should be
only the netd daemon, would not be able to invoke the syscall write/read
on a file labeled with typ hm_phonebookaccess.
With that said, netd is not reading that file, its doing other things
related to network management. When you create a socket on Android, its
between your process and the kernel directly. Thus, all traffic flows in
from outside through the kernel network stack, into your process in your
case. That's why you need some type of labelled networking as Stephen
pointed out.
Better yet, walking around with an unauthenticated http port dishing out
your database information, is not a good design, and no amount of security
technology will make up for poor designs. If you need remote interface,
ensure you authenticate properly, perhaps via ssh or another known secure
protocol.
>
> Regards,
> Souvik
> ________________________________________
> From: Stephen Smalley [[email protected]]
> Sent: Wednesday, May 13, 2015 10:03 PM
> To: Datta, Souvik; [email protected]
> Subject: Re: Assigning domain and type to platform application and its
> data
>
> 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].
>
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
