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$ <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 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. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
