I'm sorry that I could not recognize cc. Then could you let me know how to check the policy version and how to check the setool version ?
2013/11/8 Stephen Smalley <s...@tycho.nsa.gov> > Please send questions to the seandroid-list or at least cc seandroid, > and not just to me. Anyway, you just need a version of setools that is > up-to-date with support for that policy version. Use a recent version > of Fedora and you'll be fine. Recent versions of Debian or Ubuntu > should also have the support, but I don't know for sure what versions. > > On 11/08/2013 01:14 AM, Jaejyn Shin wrote: > > I met error like below > > > > ~/temp$ <jaejyn.shin@lge-security-desktop:~/temp$> sesearch -A -s rild > -t > > rild -c socket sepolicy > > ERROR: policydb version 26 does not match my version range 15-24 > > ERROR: Unable to open policy sepolicy. > > ERROR: Input/output error > > > > > > How can I my sesearch tool version and my policy version ? > > > > And I have policy.conf file. > > Can't I run the command using sesearch tool and policy.conf file? > > > > Thank you > > Best regards > > > > > > 2013/10/24 Stephen Smalley <s...@tycho.nsa.gov> > > > >> No, pull the policy file from the device and check it directly using > >> sesearch. > >> > >> adb pull /sepolicy > >> sesearch -A -s rild -t rild -c socket sepolicy > >> > >> sesearch is part of the setools package in Fedora or Ubuntu/Debian. > >> > >> I suspect that the policy on the device wasn't built from the sources > >> you are looking at. > >> > >> Also check that you don't have a /data/security/sepolicy file on the > >> device, as that will override the /sepolicy file if present. > >> > >> On 10/23/2013 10:42 AM, Jaejyn Shin wrote: > >>> I got my code from Google ( > >>> https://android.googlesource.com/platform/external/sepolicy/) > >>> > >>> If there are some modifications related to unconfined, Google maybe > >>> modified it. > >>> > >>> Then I will check the recent unconfined.te from SELinux project site to > >>> compare to my unconfined.te. > >>> > >>> Thank you > >>> Best regards > >>> > >>> > >>> 2013/10/23 Stephen Smalley <s...@tycho.nsa.gov> > >>> > >>>> Well, all of those things are allowed by unconfined_domain(). > >>>> Possibilities: > >>>> - The binary /sepolicy file on that device was not built from those > >>>> sources, > >>>> - Someone modified the unconfined.te file in those sources to remove > the > >>>> allow rules? > >>>> - Someone modified the unconfined_domain() macro definition in > te_macros > >>>> in those sources to alter what it does. > >>>> > >>>> But an unconfined rild wouldn't get any of those denials. Honest. > >>>> > >>>> On 10/23/2013 10:16 AM, Jaejyn Shin wrote: > >>>>> unconfined_domain(rild) exist in the code. > >>>>> > >>>>> I'm sorry that I can not show you my policy files. > >>>>> > >>>>> I will check the image version of the device which generate the logs. > >>>>> > >>>>> 2013/10/23 Stephen Smalley <s...@tycho.nsa.gov> > >>>>> > >>>>>> Hmmm...then you must not have unconfined_domain(rild) in that > policy. > >>>>>> Otherwise you wouldn't get those denials. > >>>>>> > >>>>>> On 10/23/2013 10:03 AM, Jaejyn Shin wrote: > >>>>>>> Okey. The logs can be gathered from the different devices. > >>>>>>> > >>>>>>> <5>[ 27.585551 / 01-02 13:00:00.810] type=1400 > >>>>>> audit(1230901200.810:14): > >>>>>>> avc: denied { create } for pid=270 comm="rild" > >> scontext=u:r:rild:s0 > >>>>>>> tcontext=u:r:rild:s0 tclass=socket > >>>>>>> <5>[ 34.643925 / 01-07 20:28:16.959] type=1400 > >> audit(592096.959:26): > >>>>>>> avc: denied { read } for pid=904 comm="rild" > scontext=u:r:rild:s0 > >>>>>>> tcontext=u:r:rild:s0 tclass=netlink_socket > >>>>>>> <5>[ 47.174096 / 01-07 20:28:29.489] type=1400 > >> audit(592109.489:27): > >>>>>>> avc: denied { read } for pid=904 comm="rild" > scontext=u:r:rild:s0 > >>>>>>> tcontext=u:r:rild:s0 tclass=netlink_socket > >>>>>>> <5>[ 48.569500 / 01-07 20:28:30.889] type=1400 > >> audit(592110.889:34): > >>>>>>> avc: denied { write } for pid=1483 comm="RILReceiver" > name="rild" > >>>>>>> dev="tmpfs" ino=8783 scontext=u:r:radio:s0 > >>>>>>> tcontext=u:object_r:rild_socket:s0 tclass=sock_file > >>>>>>> <5>[ 48.569581 / 01-07 20:28:30.889] type=1400 > >> audit(592110.889:35): > >>>>>>> avc: denied { connectto } for pid=1483 comm="RILReceiver" > >>>>>>> path="/dev/socket/rild" scontext=u:r:radio:s0 tcontext=u:r:rild:s0 > >>>>>>> tclass=unix_stream_socket > >>>>>>> <6>[ 51.794032 / 01-07 20:28:34.109] avc: denied { set } for > >>>>>>> property=ril.card_operator scontext=u:r:radio:s0 > >>>>>>> tcontext=u:object_r:rild_prop:s0 tclass=property_service > >>>>>>> <5>[ 89.696426 / 01-08 05:29:12.019] type=1400 > >> audit(592152.019:74): > >>>>>>> avc: denied { read } for pid=413 comm="rild" > scontext=u:r:rild:s0 > >>>>>>> tcontext=u:r:rild:s0 tclass=socket > >>>>>>> <5>[ 138.993392 / 01-08 05:30:01.309] type=1400 > >> audit(592201.309:76): > >>>>>>> avc: denied { read } for pid=413 comm="rild" > scontext=u:r:rild:s0 > >>>>>>> tcontext=u:r:rild:s0 tclass=socket > >>>>>>> <5>[ 219.571626 / 01-08 05:31:21.889] type=1400 > >> audit(592281.889:77): > >>>>>>> avc: denied { write } for pid=338 comm="rild" > >>>> name="property_service" > >>>>>>> dev="tmpfs" ino=5131 scontext=u:r:rild:s0 > >>>>>>> tcontext=u:object_r:property_socket:s0 tclass=sock_file > >>>>>>> > >>>>>>> > >>>>>>> 2013/10/23 Stephen Smalley <s...@tycho.nsa.gov> > >>>>>>> > >>>>>>>> Can you show an example avc message that you are getting for rild? > >>>>>>>> > >>>>>>>> On 10/23/2013 09:11 AM, Jaejyn Shin wrote: > >>>>>>>>> Yes. you are right. I was wrong. > >>>>>>>>> untrusted_app.te do not have "confined_domain(untrusted_app)". > >>>>>>>>> > >>>>>>>>> BTW my rild.te has both of "permissive rild" and > >>>>>>>> "unconfined_domain(rild)". > >>>>>>>>> But I can see the avc logs of rild in the kernel logs. > >>>>>>>>> > >>>>>>>>> It is a little confusing. > >>>>>>>>> > >>>>>>>>> Thank you > >>>>>>>>> Best regards > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2013/10/23 Stephen Smalley <s...@tycho.nsa.gov> > >>>>>>>>> > >>>>>>>>>> If it is already unconfined, you shouldn't get any denials. > >>>>>> unconfined > >>>>>>>>>> is allowed everything (well, except what Google has started to > >>>> remove > >>>>>>>>>> from it, like loading policy). > >>>>>>>>>> > >>>>>>>>>> On 10/23/2013 08:54 AM, Jaejyn Shin wrote: > >>>>>>>>>>> Answer 1) > >>>>>>>>>>> In my android source, untrusted_app is permissive and > unconfined. > >>>>>>>>>>> But the avc logs are printing on the kernel log. > >>>>>>>>>>> I do not want see the avc log of the permissive domain like > >>>>>>>>>> untrustes_app. > >>>>>>>>>>> > >>>>>>>>>>> Answer 2) > >>>>>>>>>>> I can not write all allow of untrusted_app because I can not > >>>> predict > >>>>>>>> what > >>>>>>>>>>> avc log will be appeared. > >>>>>>>>>>> This is why I want to use "*" in the dontaudit statement. > >>>>>>>>>>> + Could you let me know a name of the tool to generate > dontaudit > >>>>>> rule? > >>>>>>>>>>> > >>>>>>>>>>> Answer 3) > >>>>>>>>>>> Okey. It looks good way. > >>>>>>>>>>> I have other permissive domains (bluetooth, dbusd, radio, nfc, > >>>>>> kernel, > >>>>>>>>>>> platform_app, release_app....). > >>>>>>>>>>> I should make the te_macro of the way you teach me to use in > the > >>>> all > >>>>>>>>>>> permissive domains. > >>>>>>>>>>> Thank you > >>>>>>>>>>> Best regards > >>>>>>>>>>> 2013/10/23 Stephen Smalley <s...@tycho.nsa.gov> > >>>>>>>>>>> > >>>>>>>>>>>> On 10/23/2013 02:45 AM, Jaejyn Shin wrote: > >>>>>>>>>>>>> I want to use dontaudit to all domains and all classes > >>>>>>>>>>>>> > >>>>>>>>>>>>> For example) > >>>>>>>>>>>>> dontaudit untrusted_app *:* * > >>>>>>>>>>>>> > >>>>>>>>>>>>> but '*' can not be used at the target_type position and also > >>>> class > >>>>>>>>>>>> position. > >>>>>>>>>>>>> > >>>>>>>>>>>>> How can I use dontaudit like this situation ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> I am referring to this site: " > >>>>>>>> http://selinuxproject.org/page/AVCRules"; > >>>>>>>>>>>> > >>>>>>>>>>>> First, let me ask why you don't want to audit any denials by > >>>>>>>>>>>> untrusted_app. > >>>>>>>>>>>> > >>>>>>>>>>>> Second, you only strictly need to dontaudit whatever isn't > >>>> allowed, > >>>>>> so > >>>>>>>>>>>> you could take the set complement of the allow rules for > >>>>>> untrusted_app > >>>>>>>>>>>> and generate dontaudit rules via a tool. > >>>>>>>>>>>> > >>>>>>>>>>>> Third, if you want to effectively dontaudit everything and do > >> not > >>>>>> want > >>>>>>>>>>>> to deal with creating such a tool, you could take the > >>>> unconfined.te > >>>>>>>>>>>> rules and copy them over to untrusted_app.te, replacing > >>>>>>>>>>>> "unconfineddomain" with "untrusted_app" and replacing "allow" > >> with > >>>>>>>>>>>> "dontaudit". unconfined.te should contain every possible > (type, > >>>>>> type, > >>>>>>>>>>>> class) triple at present, although Google is beginning to > prune > >> it > >>>>>>>> down. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
