In Depth Kernel Development Question

In Depth Kernel Development Question

Post by SethMeister » Wed, 04 Jan 1995 02:17:02



Hi,

  I was just studying up on the 4.3BSD Kernel and the setup of the
user process space.  Those of you who do not know jack about the
layoutr of the process address space probably wont understand what I
am about to ask.  Anyway, here it goes (if I am vague at any point, or
if you can tell that I am confused about something, please e-mail me,
because I am just starting to delve into kernel design).  

   The process address space is segregated into a few parts;  text,
initted data, uninitted data, user stack, a USER STRUCTURE (which in
cludes a kernel per-process stack. NOW, in the USER STRUCTURE, there
is a pointer to the PROC structure.  IN THIS PROC structure there is a
field calles uid (the user id of entity that started the process).  My
question is - this apperars to be a huge security hole, beacuse if you
could find the address of that pointer, dereference it and change the
uid in the PROC structure, then you could change the uid of the
process without using setuid.  Another part to my question is this:
is the proc structure in a read-only segment, or in kernel address
space, such that an attempt to write a new field to it in user
execution mode will result in a gp fault?  This is the only way i can
rationalize the layout of the user structure in this way (ie: you can
read your uid, but not modify it in user-mode;  in kernel mode, when
you are in [protection] ring 0, you may modify it (which you will if
you call setuid().)

 - Do you understand what I am asking?

-Seth

 
 
 

In Depth Kernel Development Question

Post by Marc Fleischma » Thu, 05 Jan 1995 05:08:18



Quote:> field calles uid (the user id of entity that started the process).  My
> question is - this apperars to be a huge security hole, beacuse if you
> could find the address of that pointer, dereference it and change the
> uid in the PROC structure, then you could change the uid of the
> process without using setuid.  Another part to my question is this:
> is the proc structure in a read-only segment, or in kernel address
> space, such that an attempt to write a new field to it in user
> execution mode will result in a gp fault?  This is the only way i can

At least in HP-UX (BSD-based) it is in the kernel address space - thus
read or write access results in a gp fault. In HP-UX, there are so-called
lightweight system calls which are e.g. used to access the uarea/proc
struct. Hope this helps.

Marc

 
 
 

1. linux kernel IDE development process question

Hello IDE people,

I'd like to get input from everyone involved in drivers/ide/ on the
current development process.

I would like to know what code is kept in sync between 2.4/2.5
(2.2/2.0?).  This way I can start by understanding what is already being
done. This is related to the recent "hdparm and removable IDE?" thread
on LKML.

I would like to start by declaring ide_hwifs[] static, and removing the
extern ide_hwifs from ide.h.  all references to ide_hwifs[] will be
converted to macros and/or access method functions, that return a
pointer to a particular ide_hwifs_t.  for_each_hwif() and replacements
for whatever else is in use will be provided as well, initially just
doing the same thing that is done now, ie iterating through ide_hwifs[].

There's more to my plan, that's just to get the discussion going.  I
will only address what can be easily merged into all currently supported
kernel trees, I just need to know what they are.

by creating a new file ide-kernel.[ch], and moving the ide_hwifs[] and
accessor functions to it, each kernel tree can implement it differently
without complicating backports for the common stuff.  Initially the
changes will *not* alter any behaviour, just jockeying stuff into place
to make that painless when the time comes.  (think about it: if the
access methods return pointers, who's going to notice when ide_hwifs[]
is replaced with a linked list?)

My motivation: I'd *really* like to be able to sell entry level PC
servers with hotswap raid1.  I'm not in a hurry, baby steps are ok, I
just want to get the ball rolling.  It's all negotiable.  I'm no expert
here.

Regards,

Jeremy
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Boot problem after memory upgade

3. Newbie question : Kernel development

4. UPDATE: ftptool 4.5 with new dll libs

5. Browser Question (Plug-ins) m-w.com

6. NEED HELP

7. Subject: Ksh93 question: special built-ins: why are they special?

8. networking with win XP

9. Firwall/forward/redierct/ipchains question

10. Kernel Color Depth Problem

11. bit depth kernel args

12. kernel/color depth problem

13. Looking for Solaris based intranet development tool for dynamic database development