Yes, 10.04 is too old. Probably need 12.10 or later. 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. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> > >> >
-- 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.
