All of lore.kernel.org
 help / color / mirror / Atom feed
From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Enable login and use the whole system from /dev/console
Date: Wed, 05 Jan 2011 10:53:07 -0500	[thread overview]
Message-ID: <4D2493E3.2030300@tresys.com> (raw)
In-Reply-To: <SNT139-w559E582B23F9C1425DDBA8AB1A0@phx.gbl>

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

  reply	other threads:[~2011-01-05 15:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-21  3:11 [refpolicy] Enable login and use the whole system from /dev/console HarryCiao
2011-01-05 15:53 ` Christopher J. PeBenito [this message]
     [not found]   ` <SNT139-w22E3978CFC050DC3020493AB0B0@phx.gbl>
     [not found]     ` <4D27187C.3050808@tresys.com>
2011-01-10 11:17       ` [refpolicy] [v2] " HarryCiao
2011-01-14 19:48         ` Christopher J. PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2493E3.2030300@tresys.com \
    --to=cpebenito@tresys.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.