[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: how do i get rid of kdeinit dominating program names - entirely
From:       Luke Kenneth Casson Leighton <lkcl () lkcl ! net>
Date:       2004-09-01 0:57:06
Message-ID: 20040901005706.GE4375 () lkcl ! net
[Download RAW message or body]

> Am Dienstag 31 August 2004 17:04 schrieb Luke Kenneth Casson Leighton:
> >
> > however it doesn't get rid of kdeinit kip_imap4.
> >
> > it doesn't get rid of kdeinit kio_file.
> >
> Well, kio_imap4 simply is no program and it's not easy to change as the
> slaves are put in a pool and are reused. But it's a worthwhile thought 
> changing that if you want to configure it. Do you have a proposal?

 yes!  an option to have pools die so they aren't reused!  please!

 the principle of selinux is that security is done by putting
 "doors" between programs - execve().

 not on fork, on exec.

 at the "door", you must present your present context who you
 are (a user), what you are running (kmail) and who you want
 to run (kio_imap4).

 then you are given a new "context" with which some permissions
 are associated (e.g. the right to open port 143).

 if you WEREN'T a user, or you WEREN'T running kmail, or
 kmail WASN'T asked to run kio_imap4, then the user CANNOT
 access port 143.


 that slaves hang around with an open socket (and are accessible
 by another program?) goes against the security principle
 under which selinux operates.

 yes, it is possible - and necessary - to specify access to the
 cache socket (which kmail would use to communicate with kio_imap4).

 can i ask a question: when you say "reused", in the case of
 kio_imap4, do you mean that kmail can disconnect and reconnect
 and the imap4 connection will still be there for it to use
 (and so no second password request)
 
 or do you mean that, for example, if i have konqueror open
 up a connection to ftp.uk.debian.org, and then i have, oh,
 i dunno... kbear do a download from the same page...

 are you telling me that kbear could end up using the same
 kio_slave???

 because if so, that's potentially ... not ideal.

 i should explain that we're talking about a timescale of at least
 a year before anyone gets round to doing such a highly detailed
 selinux policy that this becomes an issue: at the moment,
 kde programs are "glommed" into one big happy user-context.

 ... but the people who considered it [1 to 2 years ago] took one
 look at kdeinit and went "oh hell - bugger that" and didn't even
 _attempt_ to get involved.

 _in the future_, with things like SE/Linux attributes in the
 X-Server which will make it possible to guarantee that a particular
 popup on the screen _really isn't fake_ and yet it was triggered
 by a hotplug kernel event from a bluetooth device that needed a
 PIN number to connect....


 so KDE_IS_PRELINKED, and now the IO_SLAVES one are a great step
 in the right direction... but not quite far enough yet.

 l.

 

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]