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
next prev parent 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.