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
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
http://www.tresys.com | oss.tresys.com