On Fri, 2013-10-11 at 00:28 +1030, William Brown wrote:
> On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
> > On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
> > > On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
> > > > On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
> > > > > 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?
> > > >
> > > > you might want to give access to both console_device_t as well as user
> > > > terminals if it wants to use console_device_t in your test scenario
> > > >
> > > > this app can also be run non interactively in scripts so it might in
> > > > that case need to be able to rw console devices
> > > >
> > > > generally though this app gets executed from user pseudo terminals by
> > > > users ( for example from xterm, or gnome terminal or a ssh shell and so
> > > > in that case you need to allow it to use user terminals)
> > > >
> > > > have a look in /dev/ to see how the different terminals are labeled
> > > >
> > >
> > > I couldn't find anything in the documentation relating to
> > > console_device_t. I tried iotop from a tty, and that worked correctly
> > > (not sure if this was meant to be the case?).
> > >
> > > What would be the difference to the application if it were run from a
> > > script (ie iotop -b). I couldn't generate any denials with my current
> > > policy trying this .... Some more detail about the different console
> > > types (or links) would be great.
> > >
> > >
> > > Regarding the other points:
> > >
> > > Added the extra rules as you suggested to remove the avc's that were
> > > generated.
> > >
> > > I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that
> > > I didn't need it. This is likely my mistake as I saw the dgram denial,
> > > and in my research found this and added it. I guess this is a lesson in
> > > adding one or two lines at a time and testing.
> > >
> > > I have improved the interface file, adding (hopefully) better
> > > explanations.
> > >
> > > Fixed the ordering of the interface calls.
> > >
> > > > You should use permission sets for the "self" rules to provide a
> > > > single
> > > > point of failure ( see my video )
> > >
> > > I remember you doing something different with the self rules, but I
> > > don't understand what you mean by permission sets. As far as I remember,
> > > you left them just as "self" rules? Is this the "create_socket_perms"
> > > that you use? If this is the case, is there a location where these are
> > > documented / source code to these for reference? I have added some of
> > > these, and the policy works, but I would still appreciate your advice.
> > >
> > >
> >
> > comments:
> >
> > sssd_read_public_files(iotop_t) needs to be wrapped in
> > optional_policy(`') since the sssd policy module, and functionality is
> > optional. we dont want this module to depends on the sssd module
>
> Done.
>
> >
> > You can remove the iotop_role(): its pretty useless.
>
> Do you mean this line?
>
> role iotop_roles types
> iotop_t;
>
no i mean this ( from the iotop.if file ):
########################################
## <summary>
## Role allowed to access and manage processes in the iotop domain.
## </summary>
## <param name="role">
## <summary>
## Role allowed access to iotop
## </summary>
## </param>
## <param name="domain">
## <summary>
## User domain for the role
## </summary>
## </param>
#
interface(`iotop_role',`
gen_require(`
type iotop_t;
attribute_role iotop_roles;
')
roleattribute $1 iotop_roles;
iotop_domtrans($2)
ps_process_pattern($2, iotop_t)
allow $2 iotop_t:process { signull signal sigkill };
')
>
> >
> > you will probably want to allow the iotop_t domain dac_override , since
> > it will probably often be run from a unpriv user home directory rather
> > than /root
> >
> > i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does
> > it read /etc/nsswitch.conf?
>
> I thought it did, but I have removed the line and it worked with no
> denial. I think the trap I fell into was that I tried the application in
> permissive mode without a complete set of rules, then I received other
> denials as a result, to which I added rules I didn't need.
>
> >
> > allow iotop_t self:netlink_route_socket create_socket_perms;
> > allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate
> > allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate
> > allow iotop_t self:unix_dgram_socket rw_socket_perms;
> >
> > i would probably used this instead:
> >
> > allow iotop_t self:netlink_route_socket r_netlink_socket_perms;
> > allow iotop_t self:netlink_socket create_socket_perms;
> > allow iotop_t self:unix_dgram_socket create_socket_perms;
>
> I have setup my policy to match this, but I think I'll need to read the
> differences in what those socket_perms options do before I understand it
> completely. I'll use the reference you previously gave.
>
> > o and i think you forgot to add dev_read_rand(iotop_t)
>
> It needed urandom, which is added (And it doesn't generate a denial, so
> I won't add it)
>
ok, earlier you showed me this, but yes f you cannot reproduce then
ignore it for now:
allow iotop_t random_device_t:chr_file read;
> Attached again.
>
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
