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.