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@xxxxxxxxxx> 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@xxxxxxxxxxxx > 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@xxxxxxxxxx> 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@xxxxxxxxxxxx > 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@xxxxxxxxxxxxx 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
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) +')