[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: