RE: Secure-linux and standard kernel
Amsden, Zachary (amsdenz@aavid.com)
Thu, 25 Jun 1998 15:23:21 -0400
> -----Original Message-----
> From: Rik van Riel [SMTP:H.H.vanRiel@phys.uu.nl]
>
> On Thu, 25 Jun 1998, Pavel Kankovsky wrote:
> > On 24 Jun 1998, Ulrich Drepper wrote:
> >
> > > MOLNAR Ingo <mingo@valerie.inf.elte.hu> writes:
> > >
> > > > btw, is there no room in say elf32_hdr to include 64 bits
> somehow? This
> > > > way we could load the physical capabilities mask in the kernel,
> before
> > > > _any_ user-space code is executed, in load_elf_binary().
> > >
> > > The only place is the NOTE section. It allows arbitrary data to
> be
> > >
> > > If this has only to be done for SUID binaries it is acceptable and
> > > quite easy to implement in the kernel.
> >
> > The linker transforms .note sections into PT_NOTE segments, and the
> kernel
> > loads a segment table (looking for PT_INTERP and PT_LOAD), thus no
> section
> > header examination is needed.
> >
> > However, I think a dedicated tag (PT_CAPABILITIES? -- anyone willing
> to
> > lobby for an official number? ... anyway, one can always use a
> number from
>
> This would probably be the best solution possible. We can
> have capabilities in the executable itself (tunable with
> some utility?) without needing support inside the filesystems.
>
> With in-filesystem solutions, we can forget about NFS, CODA
> and other filesystems as well, since the formats for these
> are not decided on by us.
>
> Rik.
In-filesystem solutions also break tar and many
similar programs
Zach Amsden
amsden@andrew.cmu.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu