Looks like this thread boils down to you adding some allow rules, and you still] keep seing the denial, outside of what Stephn pointed out, are you sure its NOT MLS getting in the way?
Could you post the denials or something analogous to what you're seeing? Bill On Mon, Nov 18, 2013 at 3:12 PM, Jaejyn Shin <flagon22b...@gmail.com> wrote: > I'm using Ubuntu 10.04.4 LTS. > And I upgraded all packages in the server but I still get below error > > jaejyn.shin@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 > > > 2013/11/13 Stephen Smalley <s...@tycho.nsa.gov> >> >> You can run sesearch on the policy.conf file or on the binary sepolicy >> file, both of which can be found under the out/target/product/<board> >> directory (although policy.conf is only available as an intermediate >> file). >> >> However, I had suggested running it on the binary sepolicy pulled from >> the device to ensure that what you are running on the device matches >> what is in your build tree since you indicated that you are getting >> denials that are allowed by your policy. >> >> Try updating your libsepol and setools packages. What Linux >> distro/release are you using? >> >> On 11/08/2013 09:01 PM, Jaejyn Shin wrote: >> > 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. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> > >> > -- Respectfully, William C Roberts -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message.
