Re: [refpolicy] initrc_t access to sshd /proc to adjust OOM killer
On Mon, May 05, 2008 at 12:50:22PM -0400, Daniel J Walsh wrote:
...
> Václav Ovsík wrote:
...
> > Great, I got:
> >
> > [ 19.816342] type=1400 audit(1209977556.108:5): avc: denied { write } for pid=1466 comm="S16ssh" name="oom_adj" dev=proc ino=5408 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=file
> >
> > Was caused by:
> > Policy constraint violation.
> >
> > May require adding a type attribute to the domain or type to satisfy the constraint.
> >
> > Constraints are defined in the policy sources in policy/constraints (general), policy/mcs (MCS), and policy/mls (MLS).
> >
> >
> > I expected problems to enable such thing (to write to file with context
> > of domain). Constraints in policy/constraints etc are rather complex.
> > Now I am going in the way of the least friction :) - to fill bugreport
> > against openssh-server with a patch, that will do OOM adjustment in the
> > C-code by sshd itself (like udev does).
> >
> > IMO to write into /proc/N/oom_adj can be need by administrator
> > sometimes, so there should be some role capable to write there.
> >
> > Thanks
>
> The problem is that initrc_t is running at s0 and you are trying to
> communicate with s0-s0:c0.c1024. I think at reboot this would work.
> Strange that you are logging in at s0?
...
Yes, you are right! I did ssh to machine and then run
newrole -r sysadm_r from account with default MLS - s0.
sid:~# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ user_u s0
root root s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
zito staff_u s0
When I login directly on console as root, I have context
root:sysadm_r:sysadm_t:s0-s0:c0.c1023 and after adding the TE rule:
allow sysadm_t sshd_t:file write_file_perms;
The operation
echo 0 >/proc/$(</var/run/sshd.pid )/oom_adj
was quiet! The operation in boot sshd startup script in domain initrc_t
has also level s0 only. I must learn more about MLS and play with it
a bit.
Thanks for reply.
--
Zito
Reply to: