From: dac.override@gmail.com (Dominick Grift) Date: Sun, 18 Sep 2016 12:05:50 +0200 Subject: [refpolicy] su failing in init script In-Reply-To: <67130EC7AFA3FE4E9290B03665B351F402A905@SE-EX021.groupinfra.com> References: <67130EC7AFA3FE4E9290B03665B351F402A7E8@SE-EX021.groupinfra.com> <38d681f6-1dad-9f5c-d436-917ef99ed12d@gmail.com> <67130EC7AFA3FE4E9290B03665B351F402A905@SE-EX021.groupinfra.com> Message-ID: <911a95d1-3792-6589-daf6-bf1b9ef72613@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 09/18/2016 02:01 AM, Fakim, Walid wrote: > Thanks Dom - su_exec() and changing su to runuser did the job. It's working as a PoC with runuser. Any ideas why it fails with su? Or how I could make it work with su? > > The audit logs don't show anything, even with the dontaudit rules disabled. Authentication on this server is also done via Active Directory with winbind - maybe related to that. > > Best Regards, > > Walid Fakim The usual procedure i follow is: 1. does it work in permissive mode: if yes then selinux might be blocking 2. if selinux is blocking then there should be events. Alternatively selinux aware applications might be blocking based on information from selinux (su and runuser have no selinux awareness, so we can rule that out) 3. semodule -DB to build/load the policy w/o dontaudit rules, then reproduce the issue. 4. look for *all* selinux related messages, and not just avc denials (might be role-based access control related issue or other selinux_er: ausearch -m avc,user_avc,selinux_err -ts today 5. some user space avc denials go to syslog instead of audit.log (unprivileged object managers): cat /var/log/messages | grep -i denied > > > -----Original Message----- > From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Dominick Grift via refpolicy > Sent: 17 September 2016 19:10 > To: refpolicy at oss.tresys.com > Subject: Re: [refpolicy] su failing in init script > > On 09/17/2016 07:55 PM, Fakim, Walid via refpolicy wrote: >> Hi Guys, >> >> I am having an issue with my module where in the application's init script (unfortunately I can't change the script to make it work so that's not an option for me) there is a change of user via the following: >> > > Is it possible to use "runuser" instead of "su"? The sudo role template really was not designed for this use. Better to run su, or preferably runuser without a domain transition (su_exec()) > >> === >> >> nohup su $APP_USER -c ' >> set -e >> echo $$ >appserver.pid >> exec ../sbin/appserver -Lappserver.log ' >>appserver.log >> 2>>appserver.log & >> >> === >> >> I can also see it's failing because I can see in the logs the error comes up as : >> >> Password: su: incorrect password >> >> == >> >> In the audig logs, I see -> >> >> type=AVC msg=audit(1474133015.013:80): avc: denied { entrypoint } >> for pid=1858 comm="nohup" path="/bin/su" dev=dm-0 ino=134991 >> scontext=system_u:system_r:appserver_sudo_t:s0 >> tcontext=system_u:object_r:su_exec_t:s0 tclass=file type=AVC >> msg=audit(1474133015.013:80): avc: denied { read open } for >> pid=1858 comm="nohup" name="su" dev=dm-0 ino=134991 >> scontext=system_u:system_r:appserver_init_t_init_t:s0 >> tcontext=system_u:object_r:su_exec_t:s0 tclass=file type=AVC >> msg=audit(1474133015.013:80): avc: denied { execute } for pid=1858 >> comm="nohup" name="su" dev=dm-0 ino=134991 >> scontext=system_u:system_r:appserver_init_t_init_t:s0 >> tcontext=system_u:object_r:su_exec_t:s0 tclass=file >> >> === >> >> >> In my module I tried to use the following which I thought should make it work: >> >> application_domain(appserver_init_t, appserver_init_exec_t) >> init_daemon_domain(appserver_init_t, appserver_init_exec_t) >> sudo_role_template(appserver_init, system_r, appserver_init_t) >> >> type_transition appserver_init_t su_exec_t:process >> appserver_init_sudo_t; >> sudo_exec(appserver_init_t) >> domain_subj_id_change_exemption(appserver_init_t) >> domain_system_change_exemption(appserver_init_t) >> >> ############### >> >> Some of the above is probably overkill but am clutching at straws at the moment. >> >> Any thoughts or comments please?/// >> >> >> Thanks. >> >> Best Regards, >> >> Walid Fakim >> >> >> >> >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy >> > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160918/58da3372/attachment.bin