From: guido@trentalancia.com (Guido Trentalancia)
Date: Mon, 07 Mar 2011 18:18:44 +0100
Subject: [refpolicy] [PATCH 17/34]: patch to allow plymouthd use
 unallocated ttys
In-Reply-To: <4D74E662.4030800@tresys.com>
References: <1297837126.3205.66.camel@tesla.lan>
	<4D651E49.3030300@tresys.com> <1298486079.29671.10.camel@tesla.lan>
	<4D6D47EA.6090901@tresys.com> <1299013310.14035.47.camel@tesla.lan>
	<4D74E662.4030800@tresys.com>
Message-ID: <1299518324.2978.47.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 07/03/2011 at 09.06 -0500, Christopher J. PeBenito wrote:
> On 03/01/11 16:01, Guido Trentalancia wrote:
> > On Tue, 01/03/2011 at 14.24 -0500, Christopher J. PeBenito wrote:
> >> On 02/23/11 13:34, Guido Trentalancia wrote:
> >>> Hello Christopher !
> >>>
> >>> On Wed, 23/02/2011 at 09.48 -0500, Christopher J. PeBenito wrote:
> >>>> On 02/16/11 01:18, Guido Trentalancia wrote:
> >>>>> This patch allows plymouthd to use unallocated ttys.
> >>>>>
> >>>>> diff -pruN -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-02022011/policy/modules/services/plymouthd.te refpolicy-git-02022011-new/policy/modules/services/plymouthd.te
> >>>>> --- refpolicy-git-02022011/policy/modules/services/plymouthd.te	2011-01-08 19:07:21.280747356 +0100
> >>>>> +++ refpolicy-git-02022011-new/policy/modules/services/plymouthd.te	2011-01-26 01:40:06.542176190 +0100
> >>>>> @@ -64,6 +64,8 @@ miscfiles_read_localization(plymouthd_t)
> >>>>>  miscfiles_read_fonts(plymouthd_t)
> >>>>>  miscfiles_manage_fonts_cache(plymouthd_t)
> >>>>>  
> >>>>> +term_use_unallocated_ttys(plymouthd_t)
> >>>>> +
> >>>>>  ########################################
> >>>>>  #
> >>>>>  # Plymouth private policy
> >>>>
> >>>> Why?  Would it be possible to specifically label the devices?
> >>>
> >>> I think they are unallocated not unlabelled.
> >>>
> >>> They have label tty_device_t and what is needed is chr_file { write
> >>> ioctl read open getattr append }.
> >>>
> >>> Possibly it's stuff such as /dev/tty63, /dev/hvc0 and so on.
> >>
> >> The point is that we want to isolate the access if possible.  If it only
> >> works on /dev/tty63, then we can consider giving that a different label.
> > 
> > It is defined at compile time. Basically there are two devices:
> > 
> > BOOT_TTY "/dev/tty1"
> > SHUTDOWN_TTY "/dev/tty63"
> > 
> > but the above are just the default values and they can be changed using
> > configure options.
> > 
> > Of course isolating an access is always good, but consider the above and
> > consider that this package is only used by Fedora... More or less it's a
> > just toy.
> > 
> > I am not sure that relabeling generic devices such as tty1 and tty63 is
> > a good idea.
> 
> Since the default is tty1, I'd have to agree.  Though I think its
> unfortunate.
> 
> >>> By the way, recently I had to add these (to use ftp as root from a
> >>> console):
> >>>
> >>> kernel_request_load_module(sysadm_t) in policy/modules/roles/sysadm.te
> >>> (trying to load ipv6 module)
> >>
> >> Not a problem to add this, since sysadm can actively insert modules.
> >>
> >>> corenet_tcp_bind_generic_node(sysadm_t) in
> >>> policy/modules/roles/sysadm.te (ftp list directory)
> >>
> >> My guess is this has to do with active mode FTP.
> >>
> >>> And there might be more, I am still testing...
> >>>
> >>> What am I getting wrong here ? Apparently the console is having some
> >>> issues (and perhaps not just with ftp) that are not showing up from an X
> >>> terminal... So either I am doing something wrong or what's the reason
> >>> for having a console much more restricted than X terminals ??
> >>
> >> They shouldn't be.  Perhaps the ipv6 module is loaded by the time you
> >> get X started.  As for the FTP, are you doing it as sysadm_t in X too?
> > 
> > Yes, it is probably related to the active mode. But it should be allowed
> > as sysadm_t. We need to check the console functionality carefully as
> > soon as all the other pending patches have been sorted out.
> > 
> > The ipv6 module is disabled. Of course this does not prevent new
> > requests from being made (applications do not know it's disabled)...
> > 
> > As for the ftp client, I am doing it from xdm_t under X (from a
> > "graphical" terminal). It's just one of many other things that are not
> > fully functional under the console. We'll get into all that pain soon...
> 
> If you're running as a user as xdm_t, it is the wrong domain.  If that
> is why there is a bunch of added xdm_t dbus access in your patches,
> those rules shouldn't be added.

Finally we got to the point. In fact it sounded so strange to me that
stuff was running in xdm_t !

Where did the installation fail then ?

Regards,

Guido