From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 07 Mar 2011 09:06:26 -0500
Subject: [refpolicy] [PATCH 17/34]: patch to allow plymouthd use
 unallocated ttys
In-Reply-To: <1299013310.14035.47.camel@tesla.lan>
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>
Message-ID: <4D74E662.4030800@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com