All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] systemd policy
Date: Mon, 13 Jan 2014 15:16:34 -0500	[thread overview]
Message-ID: <52D449A2.5080809@redhat.com> (raw)
In-Reply-To: <1389639753.20228.8.camel@x220.localdomain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 02:02 PM, Dominick Grift wrote:
> On Mon, 2014-01-13 at 10:10 -0500, Daniel J Walsh wrote:
> 
>> I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
>> 
>> Could you guys take care of getting systemd policy upstream.
>> 
> 
> We rely on Chris
> 
> I recently submitted a small patch just to get the ball rolling but it did
> not get any reply.
> 
> Other than that, Fedora is also to blame to an extent.
> 
> It would help if Fedora also considers things, also for its own benefit.
> 
> For example:
> 
> Fedora recently remove the init_run_daemon(unconfined_t) from her policy,
> while i submitted a solution here on this list that i believe is 
> sustainable but it was ignore without any comments.
> 
> I know Fedora does not have to , or wants to support other init systems but
> reference policy does not have that luxury. By going your own way, i 
> believe you're shutting the door to alternative init systems in Fedora and
> you decrease chances of getting stuff up streamed.
> 
> Now with every commit Fedora does i have to worry about this because i know
> Fedora seems to not care about other scenarios
> 
> And then there is the issue that i am taking a bit of distance from the 
> community. I have to focus on other things unfortunately, but ces't la vie
> 
> _______________________________________________
>> refpolicy mailing list refpolicy at oss.tresys.com 
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
Well I would not say we don't care about other init systems, since we still
need to support systemV init scripts.  I removed init_run_daemon(unconfined_t)
because it was causing us problems with "Daemons" attempting to run as
unconfined_u:system_r:unconfined_t:s0.  We are attempting to tighten security
on confined domains being able to transition to unconfined domains.  Currently
we allow unconfined domains to be entered by all file types.  We wanted to
remove this since a confined domain that transitions to an unconfined domain.
samba_t -> samba_unconfined_exec_t -> samba_unconfined_t, was only intended to
happen on scripts labeled samba_unconfined_exec_t.  But we were not blocking
the entrypoint, so potentially if samba was allowed to do
setexeccon(samba_unconfined_t) it could execute any script to get to it.

After we turned off the entrypoint ability for all confined domains, then we
saw this problem with unconfined_t.

My understanding of the auto transitions for initscripts was supposed to be

unconfined_r:unconfined_t @ *initrc_t -> system_r:initrc_t @httpd_exec_t ->
system_r:httpd_t.

The interface we removed was causing

unconfined_r:unconfined_t @ httpd_exec_t -> system_r:unconfined_t and
generating an entrypoint error.

I don't see why we want unconfined_r role changing to system_r just because it
executed a daemon domain.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLUSaIACgkQrlYvE4MpobOCBACgxHyirOGSvJCOlALbYxkdoACh
9/EAn1J/2PYe3SOK9K641BwBxSUt+BGP
=dUCz
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-01-13 20:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-12  7:06 [refpolicy] systemd policy Russell Coker
2014-01-12 12:18 ` Laurent Bigonville
2014-01-13 12:52   ` Russell Coker
2014-01-13 15:10     ` Daniel J Walsh
2014-01-13 19:02       ` Dominick Grift
2014-01-13 20:16         ` Daniel J Walsh [this message]
2014-01-13 20:22           ` Dominick Grift
2014-01-13 21:07             ` Dominick Grift
2014-01-14 14:49               ` Daniel J Walsh
2014-01-14 11:24           ` Dominick Grift
2014-01-13 23:37       ` Russell Coker
2014-01-14  9:46         ` Dominick Grift
2014-01-14  9:58           ` Dominick Grift
2014-01-14 12:35           ` Laurent Bigonville
2014-01-14 13:03             ` Dominick Grift
2014-01-27  6:56           ` Russell Coker
2014-02-06 14:40             ` Christopher J. PeBenito
2014-01-14 10:12         ` Dominick Grift
2014-01-14 12:22         ` Laurent Bigonville
2014-01-14 13:34         ` Christopher J. PeBenito
2014-01-14 13:54           ` Dominick Grift
2014-01-14 14:41           ` Laurent Bigonville
2014-01-14 14:55             ` Daniel J Walsh
2014-01-27 14:17           ` Miroslav Grepl
2014-02-06 16:32             ` Christopher J. PeBenito
  -- strict thread matches above, loose matches on Subject: below --
2015-10-19 18:17 [refpolicy] Systemd policy Christopher J. PeBenito
2015-10-20 11:35 ` Dominick Grift
2015-10-23 19:23 ` 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=52D449A2.5080809@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.