From: Joshua Brindle <jbrindle@tresys.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Ivan Gyurdiev <ivg2@cornell.edu>,
SELinux List <SELinux@tycho.nsa.gov>,
selinuxdev <selinux-dev@tresys.com>
Subject: Re: [PATCH] libsemanage/semanage - permission check for semanage
Date: Mon, 23 Jan 2006 10:40:13 -0500 [thread overview]
Message-ID: <43D4F8DD.30705@tresys.com> (raw)
In-Reply-To: <1138030160.20815.97.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Mon, 2006-01-23 at 09:51 -0500, Joshua Brindle wrote:
>
>>yes, looking at setsebool it seems correct wrt is_managed. Which warning
>>are you speaking of? In is_managed == 0 it uses
>>selinux_set_boolean_list() and on success goes to out which destroys the
>>handle and returns.
>
>
> I just mean the old libsemanage warning from the old
> is_managed()->create_store() code path, which is eliminated by your
> patch. That is a good thing, not a problem.
>
speaking of the create_store code path, That function is no longer in
use and it was primarily used for bootstrapping non-managed systems so I
didn't remove it yet but we can probably just require the package
manager or make scripts to initialize the store and remove this from the
library entirely.
>
>>Hrm.. an interesting problem. How can we determine when the fallback
>>should happen? It seems difficult to differenciate the 'not managed' and
>>'no permission to see store' cases, which means setsebool can't know
>>when to fallback and when not to. I'm not sure there is a solution to
>>this problem except to encapsulate access to booleans through
>>libsemanage clients, even in the targeted policy, which might not be
>>acceptable.
>
>
> I suspect it isn't a real issue in practice, but if we thought it was
> truly crucial, we could introduce an explicit definition of is_managed
> rather than inferring it from active module store existence, whether via
> a definition in /etc/selinux/config or some other indicator (e.g. an
> enable/disable flag in semanage.conf analogous to the one for
> setrans.conf).
>
I'd rather punt on that for now, in the case that it really matters
(policy server) the store and boolean access will all be encapsulated
and accessible only by the server.
Aside from the error string changes and the policy directory permission
check removal does anything else need to be changed before resubmission?
Should I go ahead and remove create_store?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2006-01-23 15:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 21:45 [PATCH] libsemanage/semanage - permission check for semanage Joshua Brindle
2006-01-19 22:45 ` Ivan Gyurdiev
2006-01-20 1:38 ` Joshua Brindle
2006-01-20 2:11 ` Ivan Gyurdiev
2006-01-20 2:19 ` Joshua Brindle
2006-01-20 13:54 ` Stephen Smalley
2006-01-20 14:00 ` Joshua Brindle
2006-01-20 14:24 ` Stephen Smalley
2006-01-20 14:09 ` Stephen Smalley
2006-01-20 14:04 ` Joshua Brindle
2006-01-20 15:20 ` Stephen Smalley
2006-01-20 19:14 ` Joshua Brindle
2006-01-20 20:49 ` Stephen Smalley
2006-01-20 21:25 ` Joshua Brindle
2006-01-23 14:36 ` Stephen Smalley
2006-01-23 14:51 ` Joshua Brindle
2006-01-23 15:29 ` Stephen Smalley
2006-01-23 15:40 ` Joshua Brindle [this message]
2006-01-23 15:59 ` Stephen Smalley
2006-01-23 16:05 ` Joshua Brindle
2006-01-23 16:18 ` Stephen Smalley
2006-01-26 20:40 ` Joshua Brindle
2006-01-27 15:12 ` Stephen Smalley
2006-01-27 15:17 ` Joshua Brindle
2006-01-23 16:33 ` Joshua Brindle
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=43D4F8DD.30705@tresys.com \
--to=jbrindle@tresys.com \
--cc=SELinux@tycho.nsa.gov \
--cc=ivg2@cornell.edu \
--cc=sds@tycho.nsa.gov \
--cc=selinux-dev@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.