On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote:
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
> > >
> > > > I made a 30 minute demonstration about creating policy for iotop (on
> > > > rhel6) :
https://www.youtube.com/watch?v=WcF9QkqLcKs
> > > >
> > >
> > > Fantastic. Thanks for your combined emails. It has revealed a lot to me.
> > > I'll watch your video, and will create a similar policy for iotop on
> > > Fedora. If you don't mind, I'll post it here for review once
I'm done.
> > >
> >
> > sure, you can post it but if the policy looks like the one i created in
> > my video then its ok
> >
>
> Well hopefully it does. I'm not aiming to copy your policy directly, as
> I want to learn the steps so I can write these for myself.
>
> I have already run into one issue. I have created an iotop module and
> iotop_sysadm module, but once loaded I see a number of errors in
> ausearch like:
>
> libsepol.sepol_context_to_sid: could not convert
> staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid
> libsepol.context_from_record: invalid security context:
> "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023"
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
>
>
It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is
invalid. So you should check whether the combination of these security
identifiers is valid
you can use the seinfo , semanage and sesearch tools to determine that
to determine whether your uid/gid is associated to
staff_u/s0-s0:c0.c1023:
semanage login -l |grep myadm
myadm staff_u s0-s0:c0.c1023
to determine whether the staff_u sid is associated to the sysadm_r role
and range of s0-s0:c0.c1023:
semanage user -l | grep staff_u
staff_u user s0 s0-s0:c0.c1023
staff_r sysadm_r system_r unconfined_r
to determine whether staff_r can manually change to sysadm_r:
sesearch --role_allow | grep "allow staff_r " | grep sysadm_r
allow staff_r sysadm_r;
to determine whether the sysadm_r role is associated to the iotop_t
domain:
seinfo -xrsysadm_r | grep iotop
iotop_t
This is the only one that's missing. The rest are all correct as your
examples show.
Solved, by adding:
role iotop_roles types
iotop_t;
to my te file.
to determine whether whether sysadm_t automatically domain transitions
to iotop_t when he runs a file with type iotop_exec_t:
sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition
type_transition sysadm_t iotop_exec_t : process iotop_t;
if all the above prerequisites are met then things should probably work
in the default fedora/rhel set up
What is the difference between userdom_use_user_terminals and
term_use_console? I assume that since the latter is in the kernel
section, it's related to actually terminals ie ttys?
As per the net_admin capability, removing it iotop gives this friendly
spiel:
Netlink error: Operation not permitted (1)
The Linux kernel interfaces that iotop relies on now require root
priviliges
or the NET_ADMIN capability. This change occured because a security
issue
(CVE-2011-2494) was found that allows leakage of sensitive data across
user
boundaries. If you require the ability to run iotop as a non-root user,
please
configure sudo to allow you to run iotop as root.
Please do not file bugs on iotop about this.
I have attached my version of the policy.
It still receives a small number of denials, that audit2allow lists
here:
#============= iotop_t ==============
allow iotop_t passwd_file_t:file read;
allow iotop_t random_device_t:chr_file read;
#!!!! This avc can be allowed using the boolean 'global_ssp'
allow iotop_t urandom_device_t:chr_file read;
But these don't prevent iotop working.
I would appreciate if you could review this policy. Thanks again for
your help.
--
Sincerely,
William Brown
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xEFC416D781A8099A