From mboxrd@z Thu Jan 1 00:00:00 1970 From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 05 Jan 2011 10:53:07 -0500 Subject: [refpolicy] Enable login and use the whole system from /dev/console In-Reply-To: References: Message-ID: <4D2493E3.2030300@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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