On 26/03/08 15:57, Christopher J. PeBenito wrote: > On Fri, 2008-03-21 at 08:31 +0100, Václav Ovsík wrote: >> 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. Ah, that explains a lot. >> 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. > >> 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. > > As I recall it was a work in progress by either Erich or Manoj. If it > was never finished or abandoned, then it should probably be removed. Because of dpkg_domtrans_script(dpkg_t) maintainer scripts written in shell (i.e. most) are run in dpkg_script_t, but any written in something else (usually Perl) stay in dpkg_t. So at the moment a bunch of rules are needed for both domains, which is not very sensible. -- Martin Orr -- 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.
