From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH v2 2/6] Allow init scripts to handle sysctls
Date: Tue, 03 Jul 2012 09:59:52 -0400 [thread overview]
Message-ID: <4FF2FAD8.8010202@tresys.com> (raw)
In-Reply-To: <20120702201951.GA19551@siphos.be>
On 7/2/2012 4:19 PM, Sven Vermeulen wrote:
> On Mon, Jul 02, 2012 at 10:47:43AM -0400, Christopher J. PeBenito wrote:
>>> allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
>>> -allow initrc_t self:capability ~{ sys_admin sys_module };
>>> +allow initrc_t self:capability ~{ sys_module };
>>> dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
>>> allow initrc_t self:passwd rootok;
>>> allow initrc_t self:key manage_key_perms;
>>
>> We typically try to separate out the sys_admin privileges since its so broad. Can a new domain be created?
>
> Its the init script calling the sysctl binary. We currently don't hold a
> separate domain for sysctl, but that's certainly doable. I guess it would
> start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
>
> But for some reason I think this has been thought of before - sysctl's are
> well known throughout the policy (with specific labels for kernel sysctl's
> and such). Was a new domain for sysctl's not done because there was little
> need for, or am I missing something?
My guess is that its a new capability check, or its a capability check for a sysctl that isn't often set.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2012-07-03 13:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-28 19:17 [refpolicy] [PATCH v2 0/6] Updates on init scripts and udev (mainly /run related) Sven Vermeulen
2012-06-28 19:17 ` [refpolicy] [PATCH v2 1/6] Support log location for init script logging Sven Vermeulen
2012-07-02 14:47 ` Christopher J. PeBenito
2012-06-28 19:17 ` [refpolicy] [PATCH v2 2/6] Allow init scripts to handle sysctls Sven Vermeulen
2012-07-02 14:47 ` Christopher J. PeBenito
2012-07-02 20:19 ` Sven Vermeulen
2012-07-02 20:25 ` Dominick Grift
2012-07-03 13:59 ` Christopher J. PeBenito [this message]
2012-07-03 17:49 ` Sven Vermeulen
2012-07-10 12:27 ` Christopher J. PeBenito
2012-06-28 19:17 ` [refpolicy] [PATCH v2 3/6] Supporting interfaces for the /run changes Sven Vermeulen
2012-06-28 19:17 ` [refpolicy] [PATCH v2 4/6] Allow init scripts to populate /run location Sven Vermeulen
2012-06-28 19:17 ` [refpolicy] [PATCH v2 5/6] Prepare udev interfaces for /run usage Sven Vermeulen
2012-06-28 19:17 ` [refpolicy] [PATCH v2 6/6] Allow init scripts to create and manage (udev) /run location Sven Vermeulen
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=4FF2FAD8.8010202@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.