Re: dynamic context transitions

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Mon, Nov 01, 2004 at 08:20:15AM -0500, Stephen Smalley wrote:
> On Sat, 2004-10-30 at 05:06, Luke Kenneth Casson Leighton wrote:
> >  the bit that i don't like is the possibility of a process giving itself
> >  an uncontrolled amount of access rights.
> > 
> >  what guarantees can you offer that a process can only escalate to a
> >  specific alternative set of access rights?
> > 
> >  e.g. is your proposal a bit like the file_contexts "alternate"
> >  keyword idea, where the policy contains a different context that
> >  the process can flip to?
> 
> If you look at the patch, it includes an oldcontext-to-newcontext
> dyntransition permission check for these dynamic context transitions, so
> you can control the set of domains which can be reached via dynamic
> transitions from any given domain.
 
 ... where in those domains there may or may not be the permission to
 make a transition.

 SO.

 this proposal is a little bit like seteuid-for-selinux, only not
 really, because seteuid has the ability to switch to any uid and then
 to any uid after that, ad infinitum.

 i wonder if it would help at all with samba's predicament?

 would it be possible to use this to have an smbd process
 transition to a user-based-file-access-only-context and then
 back-to-"root-like"-with-no-file-access-allowed?

	 reminder: samba's predicament is that processes on
	 a per-computer basis tend not to die, plus they can
	 be heavily reused (particularly in Terminal Server
	 situations) where one TCP connection to one smbd
	 process manages several multiplexed user requests
	 with _totally_ different user contexts.

	 [yes i know samba is badly designed in this respect:
	  it REALLY needs a threaded or threaded-like
	  architecture: a threaded client application gets
	  given a single server-side process for its remote
	  file access, which results ultimately in client-side
	  thread blocking - but leaving that aside]


 and also would it be possible to use this proposal to track
 what famd does, too?

	 [reminder: famd doesn't spawn per-user processes to
	  see what files need monitoring on a per-user basis,
	  it uses seteuid instead, just like samba (or maybe
	  setfsuid)].

 
  not that my opinion has any weight in
  these matters, but i still vastly prefer the
  "force-app-rewrites-to-make-significant-use-of-exec()"
  principle over this proposal, but i believe the proposal
  _does_ make "tracking" of existing application design
  much easier.

  whether said application design is any _good_ - samba's
  single-blocking-server-process serving
  multiple-threaded-multiple-user-context-clients multiplexed
  onto a single TCP connection being a notable example - is
  debatable.

  l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.