You just seen to be missing the level from the context, should be: u:object_r:foo_http_packet_t:s0
I've tested SECMARK and NetLabel (unlbl) on Android last year and it worked fine. > On Saturday, 16 May 2015, 7:02, "Datta, Souvik" <[email protected]> > wrote: > >T o use SECMARK, > I have enabled following configurations in the Android kernel (version 3.8.13) > > CONFIG_NETWORK_SECMARK=y > CONFIG_IP_NF_SECURITY=y > CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y > CONFIG_NETFILTER_XT_TARGET_SECMARK=y > CONFIG_NF_CONNTRACK_SECMARK=y > > I then added a policy file secmark.te at location > $MYDROID/device/<Manufacturer>/<device>/sepolicy/secmark.te - with > following contents: > > # our new secmark packet type > type foo_http_packet_t; > #Allow all other unmarked packets > allow domain unlabeled:packet { send recv}; > > Finally I added semark.te in BoardConfig.mk file. > > I then built a new boot.img and reflashed the target. > > After the target boot, at the shell prompt I tried to setup iptable rule:- > > #iptables -t security -A INPUT -p tcp --dport 4591 -j SECMARK --selctx > u:object_r:foo_http_packet_t > > I am getting following error: > ----------------------------------------- > error: <6>[ 229.314392] xt_SECMARK: invalid security context > 'u:object_r:foo_http_packet_t' > > I believe I am not able to set the security context correctly. Can you please > help me > > Thanks and Regards, > Souvik > > ________________________________________ > > From: Stephen Smalley [[email protected]] > Sent: Thursday, May 14, 2015 1:19 AM > To: [email protected]; Datta, Souvik > Cc: [email protected] > Subject: Re: Assigning domain and type to platform application and its data > > On 05/13/2015 03:22 PM, [email protected] wrote: >>> I just checked my Android kernel config file and found :- >>> CONFIG_NETWORK_SECMARK=y >>> >>> So when you mentioned that it is not setup on standard AOSP, can you >>> please explain whether I have to check some other things in AOSP. >>> >> >> Kernel support is one thing, you need to load the rules into iptables. For >> that, their is no developed support, you'd be on your own in a sense. > This >> is not currently supported by AOSP. >> >>> Moreover, I was thinking of adding following following in init.rc: >>> >>> "iptables -t security -A INPUT -p tcp --dport 4591 -j SECMARK > --selctx >>> u:object_r:http_packet_t:s0" >>> >>> AND >>> >>> "iptables -t mangle -A OUTPUT -p tcp --sport 4591 -j SECMARK > --selctx >>> u:object_r:http_packet_t:s0 >>> >> >> Josh Brindle submitted the netlabels.sh script as a one-shot service for >> these types of things, although limited you could revive it from the >> seandroid-4.3 branch and apply it: >> > https://bitbucket.org/seandroid/external-sepolicy/commits/70d4fc2243721a54cd177959e05cf81b54c4e226 >> >>> Also add the following rule in a policy file :- >>> >>> neverallow platform_app http_packet_t:packet { recv send }; >>> >>> NOTE : 4591 is the port through which the requests are being made to > the >>> http server (running in a process with domain as platform_app) to > access >>> the data base by the untrusted_app domain. >>> >>> Can you please confirm whether the above would work. >>> >> >> I think you would need to setup the initial sids for class packet as well >> as allow things labeled with the default through to all domains. Then >> label some packets specifically, and allow only access to those from >> specific domains. However, this will only ensure that traffic flows >> correctly on device, which means other processes cannot get traffic off >> that port, or access to those packets, but it doesn't prevent an > external >> entity from connecting to your http server. This is not a substitute for >> proper authentication and controls. > > If I understood his earlier email, he is trying to confine an app no > matter what it may do internally. IOW, the app may be provided by a > third party and he just wants to isolate it regardless. > > He can prevent an external entity from connecting to the server via > SECMARK through proper configuration of the iptables rules and policy. > That would be through labeling of packets on INPUT and limiting what he > allows to be recv'd. Could also distinguish loopback vs remote by > assigning different packet labels via iptables selectors. > > > > > _______________________________________________ > 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].
