[refpolicy] Enable login and use the whole system from /dev/console

[refpolicy] Enable login and use the whole system from /dev/console

[HarryCiao]

Hi Chris,
 
I remembered months ago we'd been talking about enabling the support of /dev/console so that users could log in from it and then use the system as normal. At that time you'd concluded that you may endorse the support for the console device by a boolean.
 
While, here is the patch, I've made use of the CUSTOM_BUILDOPT in build.conf to define a compile flag to trigger following supports for the /dev/console, I think a build flag would be better than a boolean in that you could enable/disable it according to the real deployment of your system.
 
Provide following supports for the /dev/console:
 1. Make it able to be used as a login device;
 2. Make users able to login from it;
 3. Make many userspace domains able to read from it, so that
     the corresponding applications could be run on the console;
 4. Make relevant domains able to relabel it as well as tty/pty devices,
     for example, you could use newrole on the console.
 5. Mark it as a secure device to change the security level.
 
Any comments just let me know, thanks a lot!
 
Best regards,
Harry 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101221/6d779552/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-login-and-use-system-from-console.patch
Type: application/octet-stream
Size: 6895 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101221/6d779552/attachment-0001.obj 

[refpolicy] Enable login and use the whole system from /dev/console

[Christopher J. PeBenito]

On 12/20/10 22:11, HarryCiao wrote:
> Hi Chris,
>  
> I remembered months ago we'd been talking about enabling the support of
> /dev/console so that users could log in from it and then use the system
> as normal. At that time you'd concluded that you may endorse the support
> for the console device by a boolean.
>  
> While, here is the patch, I've made use of the CUSTOM_BUILDOPT in
> build.conf to define a compile flag to trigger following supports for
> the /dev/console, I think a build flag would be better than a boolean in
> that you could enable/disable it according to the real deployment of
> your system.

Two things.

Build options that are being upstreamed should have proper build.conf
and Makefile support.  CUSTOM_BUILDOPT is intended for users to easily
add their own custom build options.

For this patch, I'd still prefer to use tunables rather than build
options.  While tunables are currently implemented as
conditionals/Booleans, that won't always be the case.  Eventually they
will be their own proper object, which will be resolved at link time.
i.e. build options are resolved at compile time, tunables will be
resolved at module link time, and Booleans will be resolved at run time.

> Provide following supports for the /dev/console:
>  1. Make it able to be used as a login device;
>  2. Make users able to login from it;

If users are using /dev/console, then its label should be changed from
console_device_t, so adding term_use_console() to the base user template
doesn't make sense to me.

>  3. Make many userspace domains able to read from it, so that
>      the corresponding applications could be run on the console;

I don't agree with the change in logging_send_syslog_msg().

>  4. Make relevant domains able to relabel it as well as tty/pty devices,
>      for example, you could use newrole on the console.
>  5. Mark it as a secure device to change the security level.

I can't remember if I suggested this.  Instead of adding a bunch of
rules in various places, wouldn't a tunable that adds console_device_t
to the ttynode attribute make this work naturally?

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

[refpolicy] [v2] Enable login and use the whole system from /dev/console

[HarryCiao]

Hi Chris,

Many thanks for your suggestions as for how to enable the console support, especially the one about relabeling it to user tty types when user logs in, which actually makes everything seems so easy!

Please refer to the attached v2 patch, looking forward to your further comments.

Well, I have done some basic tests with allow_console -> on:

(log in with user_u on console)

-bash-3.2$ id -Z
user_u:user_r:user_t:s0
-bash-3.2$ tty
/dev/console
-bash-3.2$ ls -Z /dev/console
crw--w----  t1 tty user_u:object_r:user_tty_device_t:s0 /dev/console
-bash-3.2$ 

(log in with sysadm on console)

root at qemu-host:/root> id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c1023
root at qemu-host:/root> tty
/dev/console
root at qemu-host:/root> ls -Z `tty` 
crw--w----  root tty root:object_r:user_tty_device_t:s0 /dev/console
root at qemu-host:/root> newrole -r secadm_r -p
Password: 
root at qemu-host:/root> id -Z
root:secadm_r:secadm_t:s0-s15:c0.c1023
root at qemu-host:/root> 
root at qemu-host:/root> getsebool allow_console
allow_console --> on
root at qemu-host:/root> sesearch -SCA -s getty_t -t console_device_t -c chr_file
Found 2 semantic av rules:
   allow getty_t console_device_t : chr_file { ioctl write getattr setattr lock append open } ; 
ET allow getty_t console_device_t : chr_file { ioctl read write getattr lock append open } ; [ allow_console ]

root at qemu-host:/root> sesearch -SCA -s local_login_t -t console_device_t -c chr_file
Found 2 semantic av rules:
   allow local_login_t console_device_t : chr_file { ioctl write getattr lock append open } ; 
ET allow local_login_t console_device_t : chr_file { relabelfrom relabelto } ; [ allow_console ]

root at qemu-host:/root> sesearch -SC --type -t console_device_t
Found 11 semantic te rules:
ET type_change auditadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change user_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change secadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change staff_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change sysadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change xguest_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change guest_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change logadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change webadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change dbadm_t console_device_t : chr_file user_tty_device_t; [ allow_console ]
ET type_change unconfined_t console_device_t : chr_file user_tty_device_t; [ allow_console ]

root at qemu-host:/root> 


Thanks!
Harry


> Date: Fri, 7 Jan 2011 08:43:24 -0500
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> Subject: Re: Enable login and use the whole system from /dev/console
> 
> On 01/07/11 04:25, HarryCiao wrote:
> > Hi Chris,
> > 
> > Many thanks for your comments!
> > 
> > I agree that once user logs in from /dev/console, we'd better relabel it
> > from console_device_t to something else, say user_devconsole_t, and add
> > that to securetty_types. (Indeed I should have thought about this myself)
> 
> No, it should be relabeled to the currently existing tty type,
> user_tty_device_t.  No need to differentiate a terminal that is a
> standard tty and one that is actually /dev/console.
> 
> > I didn't know about the difference between tunable and boolean, I will
> > learn how to use it and come up with another patches soon.
> > 
> > Have a nice weekend!
> > 
> > Thanks again,
> > Harry
> > 
> > 
> >> Date: Wed, 5 Jan 2011 10:53:07 -0500
> >> From: cpebenito at tresys.com
> >> To: harrytaurus2002 at hotmail.com
> >> CC: refpolicy at oss.tresys.com
> >> Subject: Re: Enable login and use the whole system from /dev/console
> >>
> >> On 12/20/10 22:11, HarryCiao wrote:
> >> > Hi Chris,
> >> >
> >> > I remembered months ago we'd been talking about enabling the support of
> >> > /dev/console so that users could log in from it and then use the system
> >> > as no rmal. At that time you'd concluded that you may endorse the
> > support
> >> > for the console device by a boolean.
> >> >
> >> > While, here is the patch, I've made use of the CUSTOM_BUILDOPT in
> >> > build.conf to define a compile flag to trigger following supports for
> >> > the /dev/console, I think a build flag would be better than a boolean in
> >> > that you could enable/disable it according to the real deployment of
> >> > your system.
> >>
> >> Two things.
> >>
> >> Build options that are being upstreamed should have proper build.conf
> >> and Makefile support. CUSTOM_BUILDOPT is intended for users to easily
> >> add their own custom build options.
> >>
> >> For this patch, I'd still prefer to use tunables rather than build
> >> options. While tunables are currently implemented as
> >> conditionals/Booleans, that won't always be the case. Eventually they
> >> will be their own proper obje ct, which will be resolved at link time.
> >> i.e. build options are resolved at compile time, tunables will be
> >> resolved at module link time, and Booleans will be resolved at run time.
> >>
> >> > Provide following supports for the /dev/console:
> >> > 1. Make it able to be used as a login device;
> >> > 2. Make users able to login from it;
> >>
> >> If users are using /dev/console, then its label should be changed from
> >> console_device_t, so adding term_use_console() to the base user template
> >> doesn't make sense to me.
> >>
> >> > 3. Make many userspace domains able to read from it, so that
> >> > the corresponding applications could be run on the console;
> >>
> >> I don't agree with the change in logging_send_syslog_msg().
> >>
> >> > 4. Make relevant domains able to relabel it as well as tty/pty devices,
> >> > for example, you could use newrole on the console.
> >> ; > 5. Mark it as a secure device to change the security level.
> >>
> >> I can't remember if I suggested this. Instead of adding a bunch of
> >> rules in various places, wouldn't a tunable that adds console_device_t
> >> to the ttynode attribute make this work naturally?
> >>
> >> --
> >> Chris PeBenito
> >> Tresys Technology, LLC
> >> www.tresys.com | oss.tresys.com
> 
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110110/d69db41e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Enable-login-from-console.patch
Type: text/x-patch
Size: 3286 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110110/d69db41e/attachment.bin 

[refpolicy] [v2] Enable login and use the whole system from /dev/console

[Christopher J. PeBenito]

On 01/10/11 06:17, HarryCiao wrote:
> Hi Chris,
> 
> Many thanks for your suggestions as for how to enable the console
> support, especially the one about relabeling it to user tty types when
> user logs in, which actually makes everything seems so easy!
> 
> Please refer to the attached v2 patch, looking forward to your further
> comments.

Merged.  I renamed allow_console to console_login.

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