[refpolicy] [PATCH 17/34]: patch to allow plymouthd use unallocated ttys

[cpebenito@tresys.com (Christopher J. PeBenito)]

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