Re: Triggers status?
On Mon, 22 Oct 2007 23:15:13 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
> On Sun, Oct 21, 2007 at 11:30:08PM -0500, Manoj Srivastava wrote:
>> On Mon, 22 Oct 2007 07:01:33 +1000, Anthony Towns wrote: This is
>> because the default is to deny by default -- and thus security policy
>> modules _add_ the permissions for special tasks that packages need to
>> do. Lacking security policy does not mean you have a security hole
>> --
> Oh, well in that case you only need it to happen before the postinst,
> not before the preinst. That's much closer to something triggers could
> do -- for instance, if you hacked libc6 to be interested in a file
> trigger for /, then anytime you installed an arch:any package, you'd
> have:
Unfortunately, that would mean a different hack for dpkg, or a
relabel; current dpkg has been patched to correctly set the file label
as things are unpacked. So, if the proper file contexts are not in
place before the unpack happens, installing the policy _after_ the fat
is not enough -- we need to correct the permissions, which is messier.
Also, while I am reasonably convinced the short period of time
between unpack and postinst with the wrong permissions does not open
security holes, this is based on an offhand analysis of the security
policy; not on any formal information flow analysis, so I would much
prefer _not_ to have this window with wrong security labels to exist in
the first place.
So, once I have some time, I'll be looking into doing an early
hook, rather than trying to coerce triggers to do the task.
Interesting suggestion, though.
manoj
--
It gets late early out there. Yogi Berra
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: