[DSE-Dev] refpolicy: domains need access to the apt's pty and fifos
Václav Ovsík
vaclav.ovsik at i.cz
Fri Mar 21 07:31:58 UTC 2008
Hi,
sorry for a delay. Beforehand thanks for all worth reactions. I'm very
thankful for these.
BTW: I found, that dpkg passes (and should not) to child processes
a file descriptor of apt pipe:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471488
The access to apts fifo should not be needed for dpkg scripts.
On Wed, Mar 05, 2008 at 05:24:28PM +0100, Erich Schubert wrote:
> Hi,
> Back when I did the initial apt_t policy, I was considering to setup
> domains such as apt_script_t and run the package installation scripts in
> this domain. This would have been similar to the rpm_script_t domain.
> However getting the files in /var/lib/dpkg/info/ labeled correctly would
> probably have required some patches to dpkg. There are non-executable
> files in there as well, and I'm not sure if you'd want to mix them up.
> For example, there are files there storing reference md5sums, or listing
> package contents. apt_script_exec_t doesn't sound appropriate for them.
> But having them in the same directory means we can't use automatic file
> type transitions.
>
> The amount of things done in postinst scripts is one of the things that
> really scares me from a security point of view. It might be very
> valuable to use a tight SELinux policy to restrict these scripts,
> however when it comes down to having a SELinux policy package update it
> becomes a Catch-22 somewhat.
> It would definitely help to have separate apt_t and apt_script_t
> domains, though, to be able to differentiate access for installation
> scripts and the package manager itself.
>
> P.S. Thanks for the great work you've been doing on the SELinux policy
> for Debian these days! THANKS!
>
> best regards,
> Erich Schubert
> --
> erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
> There was never a good war or a bad peace. - Benjamin Franklin //\
> Liebe ist eine schwere Geisteskrankheit (Platon) V_/_
>
On Thu, Mar 06, 2008 at 09:17:16PM +1100, Russell Coker wrote:
> On Thursday 06 March 2008 03:24, Erich Schubert <erich at debian.org> wrote:
> > Back when I did the initial apt_t policy, I was considering to setup
> > domains such as apt_script_t and run the package installation scripts in
> > this domain. This would have been similar to the rpm_script_t domain.
>
> I don't believe that it is possible to gain any security benefit from
> splitting dpkg_t, apt_t, and a domain for the scripts.
>
> If apt decides that a certain package is to be installed then dpkg will not
> object, therefore granting apt less privileges than dpkg will not give any
> real benefit.
>
> Pre/post install/remove scripts in Debian packages may do almost anything -
> and often do. Any restrictions on what such scripts may do will break large
> numbers of packages. Unless we can get changes to Debian policy relating to
> what such scripts may do (which seems quite unlikely) then we have to allow
> writing to almost all files in the system.
>
> > The amount of things done in postinst scripts is one of the things that
> > really scares me from a security point of view. It might be very
> > valuable to use a tight SELinux policy to restrict these scripts,
> > however when it comes down to having a SELinux policy package update it
> > becomes a Catch-22 somewhat.
> > It would definitely help to have separate apt_t and apt_script_t
> > domains, though, to be able to differentiate access for installation
> > scripts and the package manager itself.
>
> What meaningful restrictions can be applied to one but not the other?
>
> --
> russell at coker.com.au
> http://etbe.coker.com.au/ My Blog
>
> http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
On Thu, Mar 06, 2008 at 01:13:59PM +0100, Erich Schubert wrote:
> Hello Russel,
> > > It would definitely help to have separate apt_t and apt_script_t
> > > domains, though, to be able to differentiate access for installation
> > > scripts and the package manager itself.
> > What meaningful restrictions can be applied to one but not the other?
>
> I agree with you that we would currently have to allow pretty much any
> access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> obviously.
> No, I can't really think of ways to restrict dpkg_script_t apart from
> not messing with the dpkg_t state files. Maybe we could make some policy
> that /usr is to be modified by dpkg_t only whereas dynamically generated
> files have to reside in /var, but I doubt this would currently hold.
> And after all, dpkg_script_t needs to be able to even add users
> to /etc/passwd (although through the helper applications, not directly).
>
> best regards,
> Erich Schubert
> --
> erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
> The early bird gets the worm, but the second mouse gets the cheese. //\
> Ein Freund ist ein Geschenk, das man sich selbst macht. V_/_
>
On Thu, Mar 06, 2008 at 11:46:54PM +1100, Russell Coker wrote:
> On Thursday 06 March 2008 23:13, Erich Schubert <erich at debian.org> wrote:
> > > > It would definitely help to have separate apt_t and apt_script_t
> > > > domains, though, to be able to differentiate access for installation
> > > > scripts and the package manager itself.
> > >
> > > What meaningful restrictions can be applied to one but not the other?
> >
> > I agree with you that we would currently have to allow pretty much any
> > access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> > again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> > obviously.
> > No, I can't really think of ways to restrict dpkg_script_t apart from
> > not messing with the dpkg_t state files. Maybe we could make some policy
>
> But given that dpkg_script_t can make all manner of other changes (including
> loading a SE Linux policy) it seems rather minor to restrict access to dpkg
> state files.
>
> > that /usr is to be modified by dpkg_t only whereas dynamically generated
> > files have to reside in /var, but I doubt this would currently hold.
>
> It's a standard practice to convert the data files under /var in an upgrade.
>
> > And after all, dpkg_script_t needs to be able to even add users
> > to /etc/passwd (although through the helper applications, not directly).
>
> Yes.
>
> In fact while we have unconfined_t, the benefit of having a separate dpkg_t
> instead of using unconfined_t for installing packages doesn't seem
> significant.
>
> --
> russell at coker.com.au
> http://etbe.coker.com.au/ My Blog
>
> http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Seems to me dpkg_script_t is not used now really. Should be removed
dpkg_script_t from the refpolicy? A part of rules should be moved from
the domain dpkg_script_t to the domain dpkg_t probably if such a removal
will take place.
On Fri, Mar 07, 2008 at 10:23:32PM +0100, Stefan Schulze Frielinghaus wrote:
>
> On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > Hi,
> > running Debian Sid with HEAD refpolicy...
> > I tried to install bind9 and got some further denials for access to pty
> > and pipe of apt_t domain. This is a continuation of the patch from
> > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > witch was about apt finally.
> >
> > ...
> >
> > Attached patch solves the most of this denials, but I doubt this is the
> > right way. Should be used some attribute for this? I noticed attribute
> > privfd and macro domain_interactive_fd(), what about it? Rpm already
> > has such macro calls
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> >
> > I tried to use this macro for apt_t, and all use fd denials above are
> > solved with it. Should be things done in this way?
> >
> > Thanks for comments.
>
> I think it is not really nice to have all these allow rules directly in
> the modules. A similar discussion can be found here:
> http://marc.info/?l=selinux&m=118707242005853&w=2
>
> Especially the first replay of Stephen Smalley pointing out how rpm
> solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
>
> If I had to choose between the several fixes for every module or the
> "rpm-way" to allow all usage of file descriptors and read permissions
> then I would vote for the latter.
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
On Mon, Mar 10, 2008 at 01:39:49PM -0400, Christopher J. PeBenito wrote:
> On Fri, 2008-03-07 at 22:23 +0100, Stefan Schulze Frielinghaus wrote:
> > On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > > Hi,
> > > running Debian Sid with HEAD refpolicy...
> > > I tried to install bind9 and got some further denials for access to pty
> > > and pipe of apt_t domain. This is a continuation of the patch from
> > > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > > witch was about apt finally.
> > >
> > > ...
> > >
> > > Attached patch solves the most of this denials, but I doubt this is the
> > > right way. Should be used some attribute for this? I noticed attribute
> > > privfd and macro domain_interactive_fd(), what about it? Rpm already
> > > has such macro calls
> > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > >
> > > I tried to use this macro for apt_t, and all use fd denials above are
> > > solved with it. Should be things done in this way?
> > >
> > > Thanks for comments.
> >
> > I think it is not really nice to have all these allow rules directly in
> > the modules. A similar discussion can be found here:
> > http://marc.info/?l=selinux&m=118707242005853&w=2
> >
> > Especially the first replay of Stephen Smalley pointing out how rpm
> > solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> >
> > If I had to choose between the several fixes for every module or the
> > "rpm-way" to allow all usage of file descriptors and read permissions
> > then I would vote for the latter.
>
> A better option might be to mimic the inheritance of fds and pipes.
I'm not certain I understood this correctly. I understood `to mimic the
inheritance', that for all domains runnable from dpkg scripts should be
inserted appropriate rules for access explicitly. If I'm wrong, please
explain it a bit further. Sorry for my English.
Please, can you look at the attached patch snippet? The interface
identifier needs review.
Finaly I wrote apt_rw_pipes() to be consistent with the assignment/ident
of interface, although in our case (dpkg scripts) the access to apt pipe
should not be allowed. Maybe some regular child can comunicate with apt
through a pipe and can be run from dpkg script equally. Who knows :)
The interface apt_dontaudit_write_pipes() is useless than and may be
discarded.
If things are ok, I will try to search all possible domains runnable
from a dpkg script and will prepare the complete patch.
Thanks
--
Zito
-------------- next part --------------
Index: policy/modules/system/libraries.te
===================================================================
--- policy/modules/system/libraries.te.orig 2008-03-20 12:01:18.000000000 +0100
+++ policy/modules/system/libraries.te 2008-03-20 15:58:45.000000000 +0100
@@ -103,9 +103,7 @@
')
optional_policy(`
- apt_rw_pipes(ldconfig_t)
- apt_use_fds(ldconfig_t)
- apt_use_ptys(ldconfig_t)
+ apt_allow_inherited_resrc(ldconfig_t)
')
optional_policy(`
Index: policy/modules/admin/apt.if
===================================================================
--- policy/modules/admin/apt.if.orig 2008-03-20 12:00:47.000000000 +0100
+++ policy/modules/admin/apt.if 2008-03-20 15:57:47.000000000 +0100
@@ -92,6 +92,24 @@
########################################
## <summary>
+## Do not audit attempts to write apt unnamed pipes.
+## </summary>
+## <param name="domain">
+## <summary>
+## The type of the process performing this action.
+## </summary>
+## </param>
+#
+interface(`apt_dontaudit_write_pipes',`
+ gen_require(`
+ type apt_t;
+ ')
+
+ dontaudit $1 apt_t:fifo_file write;
+')
+
+########################################
+## <summary>
## Read and write an unnamed apt pipe.
## </summary>
## <param name="domain">
@@ -190,3 +208,19 @@
dontaudit $1 apt_var_lib_t:file manage_file_perms;
dontaudit $1 apt_var_lib_t:lnk_file manage_lnk_perms;
')
+
+########################################
+## <summary>
+## Allow use, read & write to inherited apts fds, pty & pipes.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`apt_allow_inherited_resrc',`
+ apt_rw_pipes($1)
+ apt_use_fds($1)
+ apt_use_ptys($1)
+')
More information about the SELinux-devel
mailing list