[DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Martin Orr]

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 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.
> 
>> 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