1. Yes, their was some generic looking denials that should be in the
base policy as well as labeling /dev/diag. I have ran into that one
myself put could not verify other devices that used it. We would
appreciate to work with you and when your done modifying the base
policy (for those generic denials) gladly review a patch with you for
integration.
2. The shell denials are usually caused by you shelling in through
adbd and running commands. You really don't want to give those
accesses. However, as a caveat, if you look for domain_auto_trans in
sepolicy we see some going to the shell domain.
android/external/sepolicy$ grep domain_auto_trans *
adbd.te:domain_auto_trans(adbd, shell_exec, shell)
shell.te:domain_auto_trans(init, shell_exec, shell)
I have noticed that init's sometimes cause denials on shell domain. An
easy way to test this is to modify this line and have init transition
(on exec of shell_exec) to someother donmain, maybe init_shell that
has no "allow" rules. This will let you see exactly what your init is
doing and then determine if those rules should be allowed, or if your
init shell exec's should run in a separate domain. I tend not to add
any more allows's to shell, and if init shell exec's are cuasing more
denials, place it into its own domain specified in per device policy.
However, this requires you to comment out or remove the transition
rule for init in shell.te
Bill
On Wed, Sep 12, 2012 at 1:50 PM, Cesar Maiorino
<cesar.maiorino@xxxxxxxxx> wrote:
> That is enormously helpful. Thanks.
>
> So I have a couple more questions:
>
> (1) I would naively expect that the denials would be more device-specific.
> For example, there are
> several related to zygote that look pretty generic. Shouldn't those already
> be in the "base" policy?
> Or am I missing something?
>
> (2) If I don't add the "shell allow" rules, how do I deal with those
> denials?
>
>
>
>
> On Wed, Sep 12, 2012 at 4:29 PM, William Roberts <bill.c.roberts@xxxxxxxxx>
> wrote:
>>
>> So you have a lot of denials. You need to correct these before you go
>> to enforcing mode.
>>
>> Below, I show you how you can use audit2allow to gather the rules to
>> add to your device policy. If you create a file called sepolicy.te in
>> your projects device directory or vendor directory with these rules it
>> should fix it. Take a look at external/sepolicy/Android.mk, that make
>> file searches vendor and device directories based on the lunch option
>> of the device being built for to automatically include specially named
>> policy files.
>>
>> The general rule of thumb is NOT to add the shell allow rules. You
>> should also use the macro's when granting access that are defined in
>> external.sepolicy/global_macros
>>
>> If you use the macro's this line:
>>
>> allow media_app ion_device:chr_file { read open };
>>
>> becomes:
>> allow media_app ion_device:chr_file r_file_perms;
>>
>> The macro's help, you should really use them. If a process asks for
>> read, it likeley needs getattr and other accesses too and the macro's
>> wrap these up cleanly for you.
>>
>> Also, never allow access to "device" or "block_device". These are
>> large domains and granting access to them is generally not a good
>> idea. This rule "allow mediaserver device:chr_file { read write ioctl
>> open };" is caused by these denied message:
>>
>> <5>[ 9.119517] type=1400 audit(11394.900:33): avc: denied { read
>> write } for pid=194 comm="mediaserver" name="diag" dev=tmpfs ino=5559
>> scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
>> tclass=chr_file
>> <5>[ 9.154951] type=1400 audit(11394.930:34): avc: denied { open
>> } for pid=194 comm="mediaserver" name="diag" dev=tmpfs ino=5559
>> scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
>> tclass=chr_file
>> <5>[ 9.185441] type=1400 audit(11394.960:35): avc: denied { ioctl
>> } for pid=194 comm="mediaserver" path="/dev/diag" dev=tmpfs ino=5559
>> scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
>>
>> which are accesses on:
>> /dev/diag
>>
>> You should relabel dev diag in sepolicy.fc (again in your
>> device/vendor directory) to some other type and grant access on it. If
>> you allow mediaserver access to device, it could then read and write
>> to a lot of stuff under /dev that you may want to not give it access
>> too. (/dev is initially labeled as device, everything else gets a
>> specific label as needed)
>>
>>
>> Example of taking dmesg output and generating rules, don't just copy
>> and paste. Read these and make sure they make sense for your
>> application... We also may want to submit some of these upstream
>> (SELinux/Google).
>>
>> $ cat /home/wroberts/Downloads/seandroid_proc_kmsg.txt | audit2allow
>>
>> #============= media_app ==============
>> allow media_app ion_device:chr_file { read open };
>> allow media_app tmpfs:dir getattr;
>>
>> #============= mediaserver ==============
>> allow mediaserver device:chr_file { read write ioctl open };
>> allow mediaserver system_data_file:file { write open };
>>
>> #============= platform_app ==============
>> allow platform_app device:chr_file { read write open };
>> allow platform_app ion_device:chr_file { read open };
>> allow platform_app system_data_file:fifo_file { write read open };
>>
>> #============= radio ==============
>> allow radio ion_device:chr_file { read open };
>>
>> #============= release_app ==============
>> allow release_app ion_device:chr_file { read open };
>>
>> #============= rild ==============
>> allow rild device:chr_file { read write open };
>> allow rild device:dir { write add_name };
>> allow rild device:sock_file { write create };
>> allow rild self:netlink_socket { bind create };
>>
>> #============= shared_app ==============
>> allow shared_app device:chr_file { read write ioctl open };
>> allow shared_app ion_device:chr_file { read open };
>>
>> #============= shell ==============
>> allow shell ctl_default_prop:property_service set;
>> allow shell ctl_rildaemon_prop:property_service set;
>> allow shell default_prop:property_service set;
>> allow shell device:chr_file { read write getattr open };
>> allow shell device:dir { read open };
>> allow shell init:fifo_file { read getattr };
>> allow shell init:unix_stream_socket { connectto read write };
>> allow shell proc:file write;
>> allow shell rootfs:file { read open };
>> allow shell self:capability { net_admin chown fsetid dac_override };
>> allow shell self:capability2 syslog;
>> allow shell sysfs:file { write setattr };
>> allow shell system_data_file:dir { write remove_name add_name setattr };
>> allow shell system_data_file:file { write create unlink open };
>> allow shell system_file:lnk_file getattr;
>> allow shell system_prop:property_service set;
>> allow shell tmpfs:chr_file { read write getattr };
>>
>> #============= surfaceflinger ==============
>> allow surfaceflinger device:chr_file { read write ioctl open };
>>
>> #============= system ==============
>> allow system device:dir { write add_name };
>> allow system device:sock_file create;
>> allow system ion_device:chr_file { read open };
>> allow system zygote:binder { receive call };
>> allow system zygote:file write;
>>
>> #============= system_app ==============
>> allow system_app ctl_default_prop:property_service set;
>> allow system_app device:chr_file { read write ioctl open };
>> allow system_app device:sock_file write;
>> allow system_app ion_device:chr_file { read open };
>> allow system_app radio_prop:property_service set;
>>
>> #============= ueventd ==============
>> allow ueventd sdcard:dir search;
>> allow ueventd sdcard:file { read getattr open };
>> allow ueventd self:capability fowner;
>>
>> #============= zygote ==============
>> allow zygote ashmem_device:chr_file execute;
>> allow zygote init:unix_stream_socket connectto;
>> allow zygote ion_device:chr_file { read open };
>> allow zygote property_socket:sock_file write;
>> allow zygote self:binder transfer;
>> allow zygote servicemanager:binder call;
>> allow zygote surfaceflinger:binder { receive call };
>> allow zygote surfaceflinger:fd use;
>> allow zygote system:binder { receive call };
>> allow zygote system_prop:property_service set;
>>
>>
>>
>>
>>
>> On Wed, Sep 12, 2012 at 11:48 AM, Cesar Maiorino
>> <cesar.maiorino@xxxxxxxxx> wrote:
>> > Here is my /proc/kmsg. I am going to dig into it myself, but if you
>> > have
>> > the time to take a look, any
>> > pointers would be appreciated.
>> >
>> > On Wed, Sep 12, 2012 at 11:37 AM, Joman Chu <jcchu@xxxxxxxxxxxxxx>
>> > wrote:
>> >>
>> >> On 09/12/2012 11:01 AM, Cesar Maiorino wrote:
>> >>
>> >> I did have these in my init.rc, but my build was not copying init.rc to
>> >> to the out directory.
>> >> I copied it over manually and rebuilt the boot.img and it now I can
>> >> change
>> >> the values.
>> >> So that is progress.
>> >> Now, however, when I toggle on SELinux, my device locks up. On reboot
>> >> it
>> >> is stuck at the
>> >> lock screen.
>> >> Thanks for the help.
>> >>
>> >> On Tue, Sep 11, 2012 at 4:37 PM, William Roberts
>> >> <bill.c.roberts@xxxxxxxxx> wrote:
>> >>>
>> >>> My guess is you need to change the permissions of /selinux/*
>> >>> (/selinux/booleans for the booleans) to system system.
>> >>>
>> >>> the init.rc needs to have chown system system for all of the booleans,
>> >>> setenforce etc
>> >>>
>> >>> chown system system /selinux/enforce
>> >>> chown -R system system /selinux/booleans
>> >>> chown system system /selinux/commit_pending_bools
>> >>>
>> >>> You'll need to patch in the recursive support or enumerate all the
>> >>> bools. The patch for recursive support can be found:
>> >>> https://android-review.googlesource.com/#/c/32220/
>> >>>
>> >>> Hope this helps.
>> >>>
>> >>>
>> >>> On Tue, Sep 11, 2012 at 1:23 PM, Cesar Maiorino
>> >>> <cesar.maiorino@xxxxxxxxx> wrote:
>> >>> > I finally got a version of seandroid (4.0.4) running on my Qualcomm
>> >>> > MSM8960
>> >>> > Mobile Development Platform. This required some manual intervention
>> >>> > as
>> >>> > the
>> >>> > patch files did not all apply cleanly, so it's possible that I've
>> >>> > messed
>> >>> > something up in the process.
>> >>> >
>> >>> > That being said, the SEManager app does not let me change any
>> >>> > settings
>> >>> > aside
>> >>> > from toggling "MAC Mode" on and off. So I can't change '"SELinux
>> >>> > Mode"
>> >>> > (stuck in permissive), and I can't change any of the Booleans.
>> >>> >
>> >>> > AVC and MAC logging seem to be working.
>> >>> >
>> >>> > Any ideas?
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Respectfully,
>> >>>
>> >>> William C Roberts
>> >>
>> >>
>> >> Perhaps you're running into AVC denials. Can you post the kernel logs
>> >> from
>> >> /proc/kmsg?
>> >
>> >
>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>
>
--
Respectfully,
William C Roberts
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
