[DSE-Dev] refpolicy: domains need access to the apt's pty and fifos
martin at martinorr.name
Wed Mar 26 21:18:42 UTC 2008
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:
>> 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,
>>>> 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).
>>> 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
>> 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.
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.
More information about the SELinux-devel