All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] system_init.patch
Date: Thu, 18 Mar 2010 13:01:04 -0400	[thread overview]
Message-ID: <4BA25C50.9090708@redhat.com> (raw)
In-Reply-To: <1268921993.5623.60.camel@gorn.columbia.tresys.com>

On 03/18/2010 10:19 AM, Christopher J. PeBenito wrote:
> On Tue, 2010-02-23 at 17:25 -0500, Daniel J Walsh wrote:
>    
>> http://people.fedoraproject.org/~dwalsh/SELinux/F13/system_init.patch
>>
>> Lots of changes to init.
>>      
> Dropping startx and system-config-services fc, as they don't make sense.
> The former stops unpriv users from running startx from the terminal,
I don't think this is a bad thing.  I don't want confined users 
transitioning to xserver_t.
>   and
> init scripts should be configured by admins, so transitioning to init
> script domains to configure init scripts seems wrong.
>    
This gets us out of system_dbusd_t system-config-services is a service, 
not an application to be run by one admin.  dbus is a client server 
mechanism.  The service has got to be running as something that can do 
its job.  In this case it is a service that starts and stops init 
scripts.  So defining a domain that can start and stops initrc scripts 
rather then just labeling it initrc_exec_t seems crazy.
> Fixed dontaudit_init_read_all_script_files() interface name to
> init_dontaudit_read_all_script_files().
>
>    
Sorry.  I applied a patch from some one else and did not notice this.
> Dropped init_t and initrc_t audit capabilities; use logging interfaces.
>
> What is an example of an init script doing a kernel module load request?
>
>    
Anything that would bring up a network device (ipv6).
> Why does initrc need to delete /dev/null?
>    
> Why does initrc need to transition to passwd?
>
>    
I can't find a reason.  For either,  I will remove and see if it comes 
back.  Although you have
allow initrc_t self:passwd rootok;

> Dropped the init_upstart addition in init_daemon_domain() as it causes
> duplicate type transition errors.
>
>    
This is just going to cause bugs as daemons move from SysV scripts to 
upstart.
I commented this out in init_ranged_daemon_domain  probably to stop 
conflicts.
#    init_daemon_domain($1,$2)

> Why would we want to allow signal inheritance?
>
>    
Appa starts initrc_t which starts a process

  reply	other threads:[~2010-03-18 17:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-23 22:25 [refpolicy] system_init.patch Daniel J Walsh
2010-03-18 14:19 ` Christopher J. PeBenito
2010-03-18 17:01   ` Daniel J Walsh [this message]
2010-03-19 12:47     ` Christopher J. PeBenito
2010-03-19 14:05       ` Daniel J Walsh
  -- strict thread matches above, loose matches on Subject: below --
2010-08-26 23:32 Daniel J Walsh
2009-11-12 22:09 Daniel J Walsh
2010-02-12 20:00 ` Christopher J. PeBenito
2010-02-13 11:59   ` Daniel J Walsh
2008-09-24 19:42 Daniel J Walsh

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=4BA25C50.9090708@redhat.com \
    --to=dwalsh@redhat.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.