Resending to the ML as the CC was lost.
Le Tue, 7 Jan 2014 18:12:07 +0100,
Laurent Bigonville <[email protected]> a ?crit :
> Le Tue, 7 Jan 2014 16:09:25 +0100,
> Sven Vermeulen <[email protected]> a ?crit :
>
> > I think in general, unconfined should remain unconfined (i.e.
> > can_exec but no domtrans). Easier to keep as a principle.
> >
> > I did make different patches in the past related to this, but have
> > since settled with this principle.
>
> I agree with you here. But it seems that both rpm and portage have a
> domtrans. I was wondering if the fact that dpkg has no such rules was
> intentional or just because it was not supporting dpkg_script_t a the
> time (or something like that).
Mhhh, actually I think the domtrans is required. dpkg now uses
its own copy of rpm_execcon()/setexecfilecon() which tries to run the
maintainer script in dpkg_exec_t.
The code uses setexeccon() to setup the exec context and will fail if
the context cannot be set.
Laurent Bigonville
PS: any reasons you have removed the cc to the ML?
On Thu, 2014-01-09 at 13:24 +0100, Laurent Bigonville wrote:
> Resending to the ML as the CC was lost.
>
> Le Tue, 7 Jan 2014 18:12:07 +0100,
> Laurent Bigonville <[email protected]> a ?crit :
>
> > Le Tue, 7 Jan 2014 16:09:25 +0100,
> > Sven Vermeulen <[email protected]> a ?crit :
> >
> > > I think in general, unconfined should remain unconfined (i.e.
> > > can_exec but no domtrans). Easier to keep as a principle.
> > >
I agree, if it was not for MLS requirements i would probably do the same
for sysadm_t
Would have been even nicer IMHO if we could get rid of those package
manager domains in general. unfortunately i do not think that is
feasible since unprivileged users sometimes are also able to use the
package managers to install files via setuid/setgid frontends.
The other compelling reasons for those domains sometimes do not apply
anymore. Like file transitions ( we have named file transitions now ),
role transitions (no need for role transitions with systemd).
Le Thu, 09 Jan 2014 14:46:48 +0100,
Dominick Grift <[email protected]> a ?crit :
> On Thu, 2014-01-09 at 13:24 +0100, Laurent Bigonville wrote:
> > Resending to the ML as the CC was lost.
> >
> > Le Tue, 7 Jan 2014 18:12:07 +0100,
> > Laurent Bigonville <[email protected]> a ?crit :
> >
> > > Le Tue, 7 Jan 2014 16:09:25 +0100,
> > > Sven Vermeulen <[email protected]> a ?crit :
> > >
> > > > I think in general, unconfined should remain unconfined (i.e.
> > > > can_exec but no domtrans). Easier to keep as a principle.
> > > >
>
> I agree, if it was not for MLS requirements i would probably do the
> same for sysadm_t
>
> Would have been even nicer IMHO if we could get rid of those package
> manager domains in general. unfortunately i do not think that is
> feasible since unprivileged users sometimes are also able to use the
> package managers to install files via setuid/setgid frontends.
rpm (and now dpkg since 1.17) are explicitly trying to run the
maintainer scripts in a specific domain (see
rpm_execcon()/setexecfilecon()).
So this means that an unconfined user trying to run dpkg in enforce
mode will get an error (my laptop is running in permissive so I didn't
saw that before) as context_type_set() will fail.
An idea how to fix this?
Cheers,
Laurent Bigonville
On Thu, 2014-01-09 at 16:57 +0100, Laurent Bigonville wrote:
> rpm (and now dpkg since 1.17) are explicitly trying to run the
> maintainer scripts in a specific domain (see
> rpm_execcon()/setexecfilecon()).
>
> So this means that an unconfined user trying to run dpkg in enforce
> mode will get an error (my laptop is running in permissive so I didn't
> saw that before) as context_type_set() will fail.
>
> An idea how to fix this?
Nope, but i think this should be at least configurable. Heck, how does
dpkg know what type to use with setexeccon? Is that hard-coded? Is there
some configuration file somewhere that it reads that tells it what type
to use? if so then maybe you can also use that to tell it when to use it
and when not?
Le Thu, 09 Jan 2014 17:12:52 +0100,
Dominick Grift <[email protected]> a ?crit :
> On Thu, 2014-01-09 at 16:57 +0100, Laurent Bigonville wrote:
>
> > rpm (and now dpkg since 1.17) are explicitly trying to run the
> > maintainer scripts in a specific domain (see
> > rpm_execcon()/setexecfilecon()).
> >
> > So this means that an unconfined user trying to run dpkg in enforce
> > mode will get an error (my laptop is running in permissive so I
> > didn't saw that before) as context_type_set() will fail.
> >
> > An idea how to fix this?
>
> Nope, but i think this should be at least configurable. Heck, how does
> dpkg know what type to use with setexeccon? Is that hard-coded? Is
> there some configuration file somewhere that it reads that tells it
> what type to use? if so then maybe you can also use that to tell it
> when to use it and when not?
Actually it's the same code as rpm currently uses.
It looks at the fcontext of the script then uses secure_compute_create
to see if a transition would occures. If it's the case it will make it
transition to that context, otherwise it's indeed using a hardcoded
context.
On Thu, 2014-01-09 at 17:19 +0100, Laurent Bigonville wrote:
>
> Actually it's the same code as rpm currently uses.
>
> It looks at the fcontext of the script then uses secure_compute_create
> to see if a transition would occures. If it's the case it will make it
> transition to that context, otherwise it's indeed using a hardcoded
> context.
hard-coding configurable security identifiers is bad practice. I would
not look too much to Fedora.
In /etc/selinux there are config files that tell selinux aware programs
what context to use in what situations. Programs should consult those
config files, then use that information to determine whether to
transition or not, and where to.
Disclaimer: thats just my opinion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/09/2014 11:36 AM, Dominick Grift wrote:
> On Thu, 2014-01-09 at 17:19 +0100, Laurent Bigonville wrote:
>
>>
>> Actually it's the same code as rpm currently uses.
>>
>> It looks at the fcontext of the script then uses secure_compute_create to
>> see if a transition would occures. If it's the case it will make it
>> transition to that context, otherwise it's indeed using a hardcoded
>> context.
>
> hard-coding configurable security identifiers is bad practice. I would not
> look too much to Fedora.
>
> In /etc/selinux there are config files that tell selinux aware programs
> what context to use in what situations. Programs should consult those
> config files, then use that information to determine whether to transition
> or not, and where to.
>
> Disclaimer: thats just my opinion
>
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
It has been like that for years. Might have been a chicken and egg problem on
initial install. RPM Now has better flexibility.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLPBeYACgkQrlYvE4MpobNlQQCfd1lT5xOndQlckBk6oEbz+/4d
4xwAn0JG5l7PPIa/CENn7/rae3daGSvl
=Y3Al
-----END PGP SIGNATURE-----
On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
> On 01/09/2014 11:36 AM, Dominick Grift wrote:
>> On Thu, 2014-01-09 at 17:19 +0100, Laurent Bigonville wrote:
>
>>>
>>> Actually it's the same code as rpm currently uses.
>>>
>>> It looks at the fcontext of the script then uses secure_compute_create to
>>> see if a transition would occures. If it's the case it will make it
>>> transition to that context, otherwise it's indeed using a hardcoded
>>> context.
>
>> hard-coding configurable security identifiers is bad practice. I would not
>> look too much to Fedora.
>
>> In /etc/selinux there are config files that tell selinux aware programs
>> what context to use in what situations. Programs should consult those
>> config files, then use that information to determine whether to transition
>> or not, and where to.
>
>> Disclaimer: thats just my opinion
>
>> _______________________________________________ refpolicy mailing list
>> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
> It has been like that for years. Might have been a chicken and egg problem on
> initial install. RPM Now has better flexibility.
bootstrapping issue - needed to know the right domain prior to any
policy files being installed on the filesystem.
Le Thu, 09 Jan 2014 15:32:03 -0500,
Stephen Smalley <[email protected]> a ?crit :
> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
> >
> > It has been like that for years. Might have been a chicken and egg
> > problem on initial install. RPM Now has better flexibility.
>
> bootstrapping issue - needed to know the right domain prior to any
> policy files being installed on the filesystem.
Does that means that rpm and dpkg are supposed to work even if the files
in /etc/selinux/<my_current_policy> are missing?
With dpkg (that use the rpm_execcon-like function) I'm getting the
following error in that case:
cannot get security labeling handle: No such file or directory
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/10/2014 06:47 AM, Laurent Bigonville wrote:
> Le Thu, 09 Jan 2014 15:32:03 -0500, Stephen Smalley <[email protected]> a
> ?crit :
>
>> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
>>>
>>> It has been like that for years. Might have been a chicken and egg
>>> problem on initial install. RPM Now has better flexibility.
>>
>> bootstrapping issue - needed to know the right domain prior to any policy
>> files being installed on the filesystem.
>
> Does that means that rpm and dpkg are supposed to work even if the files in
> /etc/selinux/<my_current_policy> are missing?
>
> With dpkg (that use the rpm_execcon-like function) I'm getting the
> following error in that case: cannot get security labeling handle: No such
> file or directory
>
I think this means you don't have a file_contexts file.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLP+lgACgkQrlYvE4MpobMXfACggj7I6iIApIJ2ttLYMoUwZH06
gjUAoI7d58sCojX6hZIA9LJnhISRapcr
=n/U5
-----END PGP SIGNATURE-----
On 01/10/2014 06:47 AM, Laurent Bigonville wrote:
> Le Thu, 09 Jan 2014 15:32:03 -0500,
> Stephen Smalley <[email protected]> a ?crit :
>
>> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
>>>
>>> It has been like that for years. Might have been a chicken and egg
>>> problem on initial install. RPM Now has better flexibility.
>>
>> bootstrapping issue - needed to know the right domain prior to any
>> policy files being installed on the filesystem.
>
> Does that means that rpm and dpkg are supposed to work even if the files
> in /etc/selinux/<my_current_policy> are missing?
>
> With dpkg (that use the rpm_execcon-like function) I'm getting the
> following error in that case:
> cannot get security labeling handle: No such file or directory
I think they always set down a pre-generated file_contexts file just for
that purpose, but otherwise weren't guaranteed any other config files.
But that was all the original rpm selinux integration; I don't know the
current state of things.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/10/2014 09:51 AM, Stephen Smalley wrote:
> On 01/10/2014 06:47 AM, Laurent Bigonville wrote:
>> Le Thu, 09 Jan 2014 15:32:03 -0500, Stephen Smalley <[email protected]> a
>> ?crit :
>>
>>> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
>>>>
>>>> It has been like that for years. Might have been a chicken and egg
>>>> problem on initial install. RPM Now has better flexibility.
>>>
>>> bootstrapping issue - needed to know the right domain prior to any
>>> policy files being installed on the filesystem.
>>
>> Does that means that rpm and dpkg are supposed to work even if the files
>> in /etc/selinux/<my_current_policy> are missing?
>>
>> With dpkg (that use the rpm_execcon-like function) I'm getting the
>> following error in that case: cannot get security labeling handle: No
>> such file or directory
>
> I think they always set down a pre-generated file_contexts file just for
> that purpose, but otherwise weren't guaranteed any other config files. But
> that was all the original rpm selinux integration; I don't know the current
> state of things.
>
Hasn't changed much, since the early years.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLQCuQACgkQrlYvE4MpobPEEwCfffqBG6rHNMWJN7tk3ATQrlQZ
9hUAnR2zACg8EXslMoevAvrHWOf7hN3n
=xlPl
-----END PGP SIGNATURE-----
Le Fri, 10 Jan 2014 09:51:17 -0500,
Stephen Smalley <[email protected]> a ?crit :
> On 01/10/2014 06:47 AM, Laurent Bigonville wrote:
> > Le Thu, 09 Jan 2014 15:32:03 -0500,
> > Stephen Smalley <[email protected]> a ?crit :
> >
> >> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
> >>>
> >>> It has been like that for years. Might have been a chicken and
> >>> egg problem on initial install. RPM Now has better flexibility.
> >>
> >> bootstrapping issue - needed to know the right domain prior to any
> >> policy files being installed on the filesystem.
> >
> > Does that means that rpm and dpkg are supposed to work even if the
> > files in /etc/selinux/<my_current_policy> are missing?
> >
> > With dpkg (that use the rpm_execcon-like function) I'm getting the
> > following error in that case:
> > cannot get security labeling handle: No such file or directory
>
> I think they always set down a pre-generated file_contexts file just
> for that purpose, but otherwise weren't guaranteed any other config
> files. But that was all the original rpm selinux integration; I don't
> know the current state of things.
Thanks.
About my initial issue with dpkg exiting if it cannot transition to
"dpkg_script_t" from unconfined users. How do you think this should be
solved? People doesn't like the transition of unconfined domains to
confined ones (I agree with this), so you think this should be fixed in
the code (setexecfilecon() or dpkg) or this could achieved in an other
way in the policy?
Cheers,
Laurent Bigonville
On 01/10/2014 12:27 PM, Laurent Bigonville wrote:
> Le Fri, 10 Jan 2014 09:51:17 -0500,
> Stephen Smalley <[email protected]> a ?crit :
>
>> On 01/10/2014 06:47 AM, Laurent Bigonville wrote:
>>> Le Thu, 09 Jan 2014 15:32:03 -0500,
>>> Stephen Smalley <[email protected]> a ?crit :
>>>
>>>> On 01/09/2014 03:26 PM, Daniel J Walsh wrote:
>>>>>
>>>>> It has been like that for years. Might have been a chicken and
>>>>> egg problem on initial install. RPM Now has better flexibility.
>>>>
>>>> bootstrapping issue - needed to know the right domain prior to any
>>>> policy files being installed on the filesystem.
>>>
>>> Does that means that rpm and dpkg are supposed to work even if the
>>> files in /etc/selinux/<my_current_policy> are missing?
>>>
>>> With dpkg (that use the rpm_execcon-like function) I'm getting the
>>> following error in that case:
>>> cannot get security labeling handle: No such file or directory
>>
>> I think they always set down a pre-generated file_contexts file just
>> for that purpose, but otherwise weren't guaranteed any other config
>> files. But that was all the original rpm selinux integration; I don't
>> know the current state of things.
>
> Thanks.
>
> About my initial issue with dpkg exiting if it cannot transition to
> "dpkg_script_t" from unconfined users. How do you think this should be
> solved? People doesn't like the transition of unconfined domains to
> confined ones (I agree with this), so you think this should be fixed in
> the code (setexecfilecon() or dpkg) or this could achieved in an other
> way in the policy?
What's wrong with transitioning from unconfined to confined? Going from
more-privileged to less-privileged is the common (and safe) case, e.g.
init -> daemon, login -> user, etc. It is confined -> unconfined
transitions that are unsafe.
On Fri, Jan 10, 2014 at 12:37:08PM -0500, Stephen Smalley wrote:
> > About my initial issue with dpkg exiting if it cannot transition to
> > "dpkg_script_t" from unconfined users. How do you think this should be
> > solved? People doesn't like the transition of unconfined domains to
> > confined ones (I agree with this), so you think this should be fixed in
> > the code (setexecfilecon() or dpkg) or this could achieved in an other
> > way in the policy?
>
> What's wrong with transitioning from unconfined to confined? Going from
> more-privileged to less-privileged is the common (and safe) case, e.g.
> init -> daemon, login -> user, etc. It is confined -> unconfined
> transitions that are unsafe.
There is nothing "wrong" with it - it's a design choice of the policy. But I
believe it is confusing for end users. They expect that, if they are running
in an unconfined context, that all actions they invoke (and which aren't
about restarting network facing daemons of course) are unconfined.
If they call rpm or another package manager, and that package manager
suddenly runs in a restricted confined domain, then they might get denials
they do not expect. After all, these are actions they are triggering that
are suddenly denied.
I'm not saying it is simple to implement this principle in practice. It
requires both sufficient work on the policies (for instance, unconfined
domains should have the right file transitions that are otherwise only
assigned to the application domains) and SELinux-aware applications.
Such applications should not only take into account the "permissive" mode
(cfr Dan's blog post on this) but also consult what the target domain should
be when a transition is requested. For instance, Portage wants to transition
to a sandbox domain (which is configured in a /etc/selinux file) but might
be even better suited if it would check what domain transition to perform,
similar to how cron daemons often work.
Wkr,
Sven Vermeulen
On 01/10/2014 01:39 PM, Sven Vermeulen wrote:
> On Fri, Jan 10, 2014 at 12:37:08PM -0500, Stephen Smalley wrote:
>>> About my initial issue with dpkg exiting if it cannot transition to
>>> "dpkg_script_t" from unconfined users. How do you think this should be
>>> solved? People doesn't like the transition of unconfined domains to
>>> confined ones (I agree with this), so you think this should be fixed in
>>> the code (setexecfilecon() or dpkg) or this could achieved in an other
>>> way in the policy?
>>
>> What's wrong with transitioning from unconfined to confined? Going from
>> more-privileged to less-privileged is the common (and safe) case, e.g.
>> init -> daemon, login -> user, etc. It is confined -> unconfined
>> transitions that are unsafe.
>
> There is nothing "wrong" with it - it's a design choice of the policy. But I
> believe it is confusing for end users. They expect that, if they are running
> in an unconfined context, that all actions they invoke (and which aren't
> about restarting network facing daemons of course) are unconfined.
>
> If they call rpm or another package manager, and that package manager
> suddenly runs in a restricted confined domain, then they might get denials
> they do not expect. After all, these are actions they are triggering that
> are suddenly denied.
>
> I'm not saying it is simple to implement this principle in practice. It
> requires both sufficient work on the policies (for instance, unconfined
> domains should have the right file transitions that are otherwise only
> assigned to the application domains) and SELinux-aware applications.
>
> Such applications should not only take into account the "permissive" mode
> (cfr Dan's blog post on this) but also consult what the target domain should
> be when a transition is requested. For instance, Portage wants to transition
> to a sandbox domain (which is configured in a /etc/selinux file) but might
> be even better suited if it would check what domain transition to perform,
> similar to how cron daemons often work.
Ok, I don't agree. That way lies madness - a never-ending set of
changes to userspace programs to re-implement everything already
provided transparently through policy domain transitions and file type
transitions.
On Fri, Jan 10, 2014 at 01:40:17PM -0500, Stephen Smalley wrote:
> >> What's wrong with transitioning from unconfined to confined? Going from
> >> more-privileged to less-privileged is the common (and safe) case, e.g.
> >> init -> daemon, login -> user, etc. It is confined -> unconfined
> >> transitions that are unsafe.
> >
> > There is nothing "wrong" with it - it's a design choice of the policy. But I
> > believe it is confusing for end users. They expect that, if they are running
> > in an unconfined context, that all actions they invoke (and which aren't
> > about restarting network facing daemons of course) are unconfined.
> >
> > If they call rpm or another package manager, and that package manager
> > suddenly runs in a restricted confined domain, then they might get denials
> > they do not expect. After all, these are actions they are triggering that
> > are suddenly denied.
> >
> > I'm not saying it is simple to implement this principle in practice. It
> > requires both sufficient work on the policies (for instance, unconfined
> > domains should have the right file transitions that are otherwise only
> > assigned to the application domains) and SELinux-aware applications.
> >
> > Such applications should not only take into account the "permissive" mode
> > (cfr Dan's blog post on this) but also consult what the target domain should
> > be when a transition is requested. For instance, Portage wants to transition
> > to a sandbox domain (which is configured in a /etc/selinux file) but might
> > be even better suited if it would check what domain transition to perform,
> > similar to how cron daemons often work.
>
> Ok, I don't agree. That way lies madness - a never-ending set of
> changes to userspace programs to re-implement everything already
> provided transparently through policy domain transitions and file type
> transitions.
The other case being extending the rights of those confined domains more and
more to suit the expectations of the end user?
The set of changes you're referring to is not never-ending, and they're
currently definitely not transparent. The amount of different approaches
taken by SELinux-aware applications is staggering and often requires
distribution SELinux maintainers to dive into the code to find out why an
application breaks in a certain way.
It would be beneficial if there was a common, documented approach on how to
deal with SELinux if SELinux-awareness is necessary.
Policy-development wise, we are still lacking enough directions (principles)
to continue to work on the policies. Right now, the community that works on
the policies (through the reference policy project) is close enough and has
sufficient discussions on all changes, but as SELinux gets more and more
used, I am expecting that the workload will increase and the number of
decisions to be taken with it.
And how to deal with unconfined domains trying to run an application is
definitely one of them.
Wkr,
Sven Vermeulen
On Fri, 2014-01-10 at 13:40 -0500, Stephen Smalley wrote:
>
> Ok, I don't agree. That way lies madness - a never-ending set of
> changes to userspace programs to re-implement everything already
> provided transparently through policy domain transitions and file type
> transitions.
>
Not sure if i am choosing my words right here but rpm_t, rpm_script_t
domains are a fallacy in the first place:
# seinfo -xaunconfined_domain_type | grep rpm
rpm_t
rpm_script_t
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On Fri, 2014-01-10 at 19:46 +0100, Sven Vermeulen wrote:
> The set of changes you're referring to is not never-ending, and they're
> currently definitely not transparent.
I agree, Whether you transition to RPM domain or not, The files will
still be created with the right context because RPM uses libselinux for
that regardless. There is no reason to domain transition to
rpm_t/rpm_script_t because that domain is as unconfined as unconfined_t.
But even if RPM did not use libselinux and we would depend on
file/domain transition rules i would still not transition to RPM domain
because unconfined_t is supposed to be able to manage the whole system
via RPM or any other route.
So the madness of the never ending story of adding file transition rules
for unconfined_t applies regardless of whether you transition to RPM or
not.
I also agree with your transparency comment. I would not call programs
(having to) hard-code types transparent.
On 01/10/2014 01:52 PM, Dominick Grift wrote:
> On Fri, 2014-01-10 at 13:40 -0500, Stephen Smalley wrote:
>
>>
>> Ok, I don't agree. That way lies madness - a never-ending set of
>> changes to userspace programs to re-implement everything already
>> provided transparently through policy domain transitions and file type
>> transitions.
>>
>
> Not sure if i am choosing my words right here but rpm_t, rpm_script_t
> domains are a fallacy in the first place:
>
> # seinfo -xaunconfined_domain_type | grep rpm
> rpm_t
> rpm_script_t
That's true. There was an original vision of confining rpm, decomposing
it, etc, that never got past the prototype stage.
On Fri, 10 Jan 2014 20:19:26 Dominick Grift wrote:
> > The set of changes you're referring to is not never-ending, and they're
> > currently definitely not transparent.
>
> I agree, Whether you transition to RPM domain or not, The files will
> still be created with the right context because RPM uses libselinux for
> that regardless. There is no reason to domain transition to
> rpm_t/rpm_script_t because that domain is as unconfined as unconfined_t.
If daemons are launched by the package management system then transitioning
from a domain like rpm_script_t or dpkg_script_t might be better than
transitioning from the domain used by the sysadmin (unconfined_t or sysadm_t).
I have the impression that Red Hat is going all systemd, so all daemons should
be launched from it instead of being launched directly. In Debian the init
issue is still being debated, but I guess we could just make systemd the
primary target and not worry too much if things don't work as well on other
systems.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Fri, 10 Jan 2014 19:52:25 Dominick Grift wrote:
> Not sure if i am choosing my words right here but rpm_t, rpm_script_t
> domains are a fallacy in the first place:
>
> # seinfo -xaunconfined_domain_type | grep rpm
> rpm_t
> rpm_script_t
That's only if you have unconfined.pp loaded. While it's not common to run
without it I aim to support such configurations in Debian and use them on some
of my systems.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Le Fri, 10 Jan 2014 13:40:17 -0500,
Stephen Smalley <[email protected]> a ?crit :
> On 01/10/2014 01:39 PM, Sven Vermeulen wrote:
> > On Fri, Jan 10, 2014 at 12:37:08PM -0500, Stephen Smalley wrote:
> >>> About my initial issue with dpkg exiting if it cannot transition
> >>> to "dpkg_script_t" from unconfined users. How do you think this
> >>> should be solved? People doesn't like the transition of
> >>> unconfined domains to confined ones (I agree with this), so you
> >>> think this should be fixed in the code (setexecfilecon() or dpkg)
> >>> or this could achieved in an other way in the policy?
> >>
> >> What's wrong with transitioning from unconfined to confined?
> >> Going from more-privileged to less-privileged is the common (and
> >> safe) case, e.g. init -> daemon, login -> user, etc. It is
> >> confined -> unconfined transitions that are unsafe.
> >
> > There is nothing "wrong" with it - it's a design choice of the
> > policy. But I believe it is confusing for end users. They expect
> > that, if they are running in an unconfined context, that all
> > actions they invoke (and which aren't about restarting network
> > facing daemons of course) are unconfined.
> >
> > If they call rpm or another package manager, and that package
> > manager suddenly runs in a restricted confined domain, then they
> > might get denials they do not expect. After all, these are actions
> > they are triggering that are suddenly denied.
> >
> > I'm not saying it is simple to implement this principle in
> > practice. It requires both sufficient work on the policies (for
> > instance, unconfined domains should have the right file transitions
> > that are otherwise only assigned to the application domains) and
> > SELinux-aware applications.
> >
> > Such applications should not only take into account the
> > "permissive" mode (cfr Dan's blog post on this) but also consult
> > what the target domain should be when a transition is requested.
> > For instance, Portage wants to transition to a sandbox domain
> > (which is configured in a /etc/selinux file) but might be even
> > better suited if it would check what domain transition to perform,
> > similar to how cron daemons often work.
>
> Ok, I don't agree. That way lies madness - a never-ending set of
> changes to userspace programs to re-implement everything already
> provided transparently through policy domain transitions and file type
> transitions.
OK, I've proposed a patch to the ML so at least dpkg will work in
enforcing mode.
If some rework on how the package manager are handled, I guess it
should be done for all of them.
Cheers,
Laurent Bigonville
On Sun, 2014-01-12 at 11:59 +1100, Russell Coker wrote:
> On Fri, 10 Jan 2014 20:19:26 Dominick Grift wrote:
> > > The set of changes you're referring to is not never-ending, and they're
> > > currently definitely not transparent.
> >
> > I agree, Whether you transition to RPM domain or not, The files will
> > still be created with the right context because RPM uses libselinux for
> > that regardless. There is no reason to domain transition to
> > rpm_t/rpm_script_t because that domain is as unconfined as unconfined_t.
>
> If daemons are launched by the package management system then transitioning
> from a domain like rpm_script_t or dpkg_script_t might be better than
> transitioning from the domain used by the sysadmin (unconfined_t or sysadm_t).
>
> I have the impression that Red Hat is going all systemd, so all daemons should
> be launched from it instead of being launched directly. In Debian the init
> issue is still being debated, but I guess we could just make systemd the
> primary target and not worry too much if things don't work as well on other
> systems.
>
I recently submitted a patch that makes DIRECT_INITRC apply to
unconfined_t as it does sysadm_t
So with the init daemons that use shell init scripts you could tune the
behaviour. If set to on, then both sysadm_r:sysadm_t as well as
unconfined_r:unconfined_t will role/domain transition on executing
"init_script_file". If its off then both unconfined_t as well as
sysadm_t run the scripts in their own domain (and then they can use
run_init is they want to implicitly run a init script file on behalf of
the system.
package managers scripts do all kind of weird stuff. Consider the
following (where even running a package manager in its own domain will
not help): a package (re)starts a daemon but not via its init script.
Then you might end up with a daemon running in the package managers
script domain (which obviously is also very permissive due to the nature
of the domain).
I still stand by my statements. If selinux aware apps like package
managers are designed properly, then running such an app without a
domain transition should not require any change to its code.
We done something similar with cron, where one can conditionally run
jobs in the user domain or in a dedicated cronjob_t domain.
The nature of package managers is that they just need a lot of
permissions. I do not see how SELinux can enforce much integrity there.
It's more of a trust thing in my view.
Unconfined_t and i guess sysadm_t need to also be able to install stuff
(consider installing apps from source (make install))
I am not saying that i think we can drop the package managers domains, i
am just saying the i think that it is more consistent to at least for
unconfined_t run package managers without a domain transition.
On Sun, 2014-01-12 at 12:04 +1100, Russell Coker wrote:
> On Fri, 10 Jan 2014 19:52:25 Dominick Grift wrote:
> > Not sure if i am choosing my words right here but rpm_t, rpm_script_t
> > domains are a fallacy in the first place:
> >
> > # seinfo -xaunconfined_domain_type | grep rpm
> > rpm_t
> > rpm_script_t
>
> That's only if you have unconfined.pp loaded. While it's not common to run
> without it I aim to support such configurations in Debian and use them on some
> of my systems.
>
Yes and if you do not have it installed then you can rest assured that
eventually RPM fails somewhere due to lack of permissions.
unconfined_domain_type was associated to rpm_t/rpm_script_t for good
reason.
On Sun, 12 Jan 2014 13:23:54 Dominick Grift wrote:
> We done something similar with cron, where one can conditionally run
> jobs in the user domain or in a dedicated cronjob_t domain.
As an aside we shouldn't use cron as an example of how to do things. It's
more of an example of a horrible series of compromises needed to build on
decades of tradition that goes in a different direction to the way we are
going.
It's probably second only to the MTA policy in terms of awkward things we have
done.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/