[uml-devel] T-mode processes

[uml-devel] T-mode processes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


The following seems to get rid of the processes:

ps ax | grep linux | awk '{print $1;}' | while read pid
do
  ( strace -p $pid ) &
done 

So, this tells me that kill-9 can't kill a process which is being
strace'ed. I really think that this is a bug.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQV9HNIqHRg3pndX9AQEsDgP9EP9IiMZYGGbUBs8Kr77fNDDfnvZyg7tw
CO20Y3kRMT0qZf5QiumuNtF4LZhadtpmw4nMINfmo/DAatrIDDzFPSadJMbxf4s5
K3U/+Ow/Q3LNybAGiKpo/X9LZ7amNrQnqxt4mOI2wHVpbO4Ued1nz8s6ZkJBJMns
FyxO+1u9C+M=
=IfWa
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Henrik Nordstrom]

On Sat, 2 Oct 2004, Michael Richardson wrote:

> So, this tells me that kill-9 can't kill a process which is being
> strace'ed. I really think that this is a bug.

It is the way it should be, even if somewhat confusing. Traced processes 
are special in many ways.


Regards
Henrik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Sunday 03 October 2004 02:26, Michael Richardson wrote:
> The following seems to get rid of the processes:
>
> ps ax | grep linux | awk '{print $1;}' | while read pid
> do
>   ( strace -p $pid ) &
> done
>
> So, this tells me that kill-9 can't kill a process which is being
> strace'ed. I really think that this is a bug.
Well, you should probably try kill -CONT before doing kill -9 (i.e. -KILL). 
Actually it makes sense that strace -p *does* kill -CONT.

> We also continue to have an issue with the /proc/PID/environ file not being
> owned by the process involved.
I'm looking at the permission in your listing and in my linux, and I don't see 
anything strange. Plus, I don't understand what you mean with "a file owned 
by a certain process".

Do you mean "I start the process with uid build and /proc/PID/* has uid root 
while it should have uid build"?

If you mean this, the answer is that you seem to be starting UML with one id 
and making it run with another UID. At least, I see this permission situation 
with the X Font Server:

root # ls -la /proc/1164/
totale 0
dr-xr-xr-x    3 xfs  xfs  0 ott  3 17:03 .
dr-xr-xr-x  125 root root 0 ott  3  2004 ..
-r--r--r--    1 root root 0 ott  3 17:03 cmdline
lrwxrwxrwx    1 root root 0 ott  3 17:03 cwd -> /
-r--------    1 root root 0 ott  3 17:03 environ
lrwxrwxrwx    1 root root 0 ott  3 17:03 exe -> /usr/X11R6/bin/xfs
dr-x------    2 root root 0 ott  3 17:03 fd
-r--r--r--    1 root root 0 ott  3 17:03 maps
-rw-------    1 root root 0 ott  3 17:03 mem
-r--r--r--    1 root root 0 ott  3 17:03 mounts
lrwxrwxrwx    1 root root 0 ott  3 17:03 root -> /
-r--r--r--    1 root root 0 ott  3 17:03 stat
-r--r--r--    1 root root 0 ott  3 17:03 statm
-r--r--r--    1 root root 0 ott  3 17:03 status

> This keeps our automatic cleaner from 
> getting the processes which are strays.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Henrik" == Henrik Nordstrom <uml@hno.marasystems.com> writes:
    >> So, this tells me that kill-9 can't kill a process which is being
    >> strace'ed. I really think that this is a bug.

    Henrik> It is the way it should be, even if somewhat
    Henrik> confusing. Traced processes are special in many ways.

  It may well be, but it isn't acceptable.
  What would break if kill-9 got rid of processes being PTRACE'ed?

  If we need to change the behaviour for tracing used in UML (or if
SYSEMU can have this behaviour), I would be much happier.
  Alternatively, if this is a question of writing "killuml" which can 
get it out of PTRACE state and -9 it, then we should put that into the
umltools. 

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQWA2NIqHRg3pndX9AQGUMgP/ZeOAdqHLOIJ41dr3r+k/Z7syduD8aUjZ
Qv16cyi3Q9IC4yOXPx96BeQPfJRsSDDuMP49eCPxdatACooTOM+bmHwjEIijc85v
XoFvcXtaQ25OVEqevVLU3dltsULX4yhVkd1BCYIhxyAHiTNawueFW0L0lukfuKJx
RqZu8YxhpVk=
=Rj37
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "BlaisorBlade" == BlaisorBlade  <blaisorblade_spam@yahoo.it> writes:
    >> We also continue to have an issue with the /proc/PID/environ file
    >> not being owned by the process involved.

    BlaisorBlade> I'm looking at the permission in your listing and in
    BlaisorBlade> my linux, and I don't see anything strange. Plus, I
    BlaisorBlade> don't understand what you mean with "a file owned by a
    BlaisorBlade> certain process".

    BlaisorBlade> Do you mean "I start the process with uid build and
    BlaisorBlade> /proc/PID/* has uid root while it should have uid
    BlaisorBlade> build"?

  Yes.

    BlaisorBlade> If you mean this, the answer is that you seem to be
    BlaisorBlade> starting UML with one id and making it run with
    BlaisorBlade> another UID. At least, I see this permission situation
    BlaisorBlade> with the X Font Server:

  No, this is not the case.
  It runs as "build" and that is all. 

  The problem is that the use of mm confuses the proc-permission system
into thinking that the process is setuid. I wandered through this last
year, when we first noticed this problem.

  This seems to be due to how mm->dumpable is initalized.
(see task_dumpable in fs/proc/base.c)
  I tried to change it, but I was not successful. I can dig up my
attempts, but they are on the list.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQWA6ZoqHRg3pndX9AQHq4wQAicuhD6K2kVa9RAKpeuHxQoqEMaHsmES8
VBvblPm6DWFlo44ti2EFHK2+TxGHNRY3o7I2IAiodcB8L9YVUv2vZT+imnqbhUZ+
OHRv+qyuWPcPL3r8pZt7h4UecNhgHL5r+D7JRoYqia6UefQ9F0SHJMdo3hpgyPQP
XY31FzFQcrM=
=lEFE
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Henrik Nordstrom]

On Sun, 3 Oct 2004, Michael Richardson wrote:

> It may well be, but it isn't acceptable.
> What would break if kill-9 got rid of processes being PTRACE'ed?

This discussion probably is more related to lkml than uml..

For one thing the SIGKILL needs to be notified to and acted upon by the 
tracing parent process before it is delivered to the killed process. It is 
possible (and certainly so in case of UML) that the tracing parent wants 
to do something entirely different when a traced whild receives SIGKILL or 
other terminal action.

The actual question is why a process can be left in traced state without 
any parent tracing it.. You'll see the same symptoms if you strace a 
process and then kills strace. My guess is that this is from the basic 
question on how to determine what to do with the traced process when the 
tracing parent disappears without telling what the future fate of this 
process should be.. neither killing or untracing the process is safe 
options.

Any way, sending a SIGCONT to the stopped process gets it going again, or 
killed in case a SIGKILL or other terminal action is pending.

Regards
Henrik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Henrik" == Henrik Nordstrom <uml@hno.marasystems.com> writes:
    >> It may well be, but it isn't acceptable.  What would break if
    >> kill-9 got rid of processes being PTRACE'ed?

    Henrik> This discussion probably is more related to lkml than uml..

  Sure.

    Henrik> For one thing the SIGKILL needs to be notified to and acted
    Henrik> upon by the tracing parent process before it is delivered to
    Henrik> the killed process. It is possible (and certainly so in case
    Henrik> of UML) that the tracing parent wants to do something
    Henrik> entirely different when a traced whild receives SIGKILL or
    Henrik> other terminal action.

  I can't see a use for this :-)

  At least, when the tracing process has gone away, then the SIGKILL
should take effect.

    Henrik> The actual question is why a process can be left in traced
    Henrik> state without any parent tracing it.. You'll see the same
    Henrik> symptoms if you strace a process and then kills strace. My
    Henrik> guess is that this is from the basic question on how to
    Henrik> determine what to do with the traced process when the
    Henrik> tracing parent disappears without telling what the future
    Henrik> fate of this process should be.. neither killing or
    Henrik> untracing the process is safe options.

    Henrik> Any way, sending a SIGCONT to the stopped process gets it
    Henrik> going again, or killed in case a SIGKILL or other terminal
    Henrik> action is pending.

  Our test bed produces a dozen of these every night.
  If someone has an idea on how to get better intel on this, I'm happy
to cooperate.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQWBHXoqHRg3pndX9AQEa6QP/TueVomIuseyLAuF9ZyUadncSwrQXIM3H
aGBul3l1mmtCr34G0f1vJItvWXUW1MDLZ+hHiFIIh63zkeOWboklKMrRbSPxFC13
Er2peBRxNZ+EGUosEQaMcKktxHn9ktoWifHzcOwvUITTVp4DT+Sp9AuTNObMqTBG
ZIEPnFmjPSg=
=Vub3
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Sunday 03 October 2004 20:39, Michael Richardson wrote:
> >>>>> "Henrik" == Henrik Nordstrom <uml@hno.marasystems.com> writes:

>
>     Henrik> Any way, sending a SIGCONT to the stopped process gets it
>     Henrik> going again, or killed in case a SIGKILL or other terminal
>     Henrik> action is pending.
>
>   Our test bed produces a dozen of these every night.
>   If someone has an idea on how to get better intel on this, I'm happy
> to cooperate.
If you want to change the behaviour on such a point, you should convince 
top-level hackers on the LKML. Quite frankly, I guess that they will say 
'NO'; and they will add "Who ever said that SIGKILL always works?". And if Al 
Viro reads your post, his answer could be very bad (Al Viro is famous for the 
way he flames newbie kernel hackers).

That said, this just means you need to fix the automated reaper. Changing this 
in the SKAS patch is not an option (I don't have time to describe this). Even 
because I think the behaviour is correct, and it's hard to change that.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Sunday 03 October 2004 19:44, Michael Richardson wrote:
> >>>>> "BlaisorBlade" == BlaisorBlade  <blaisorblade_spam@yahoo.it> writes:
>     >> We also continue to have an issue with the /proc/PID/environ file
>     >> not being owned by the process involved.
>
>     BlaisorBlade> I'm looking at the permission in your listing and in
>     BlaisorBlade> my linux, and I don't see anything strange. Plus, I
>     BlaisorBlade> don't understand what you mean with "a file owned by a
>     BlaisorBlade> certain process".
>
>     BlaisorBlade> Do you mean "I start the process with uid build and
>     BlaisorBlade> /proc/PID/* has uid root while it should have uid
>     BlaisorBlade> build"?
>
>   Yes.
>
>     BlaisorBlade> If you mean this, the answer is that you seem to be
>     BlaisorBlade> starting UML with one id and making it run with
>     BlaisorBlade> another UID. At least, I see this permission situation
>     BlaisorBlade> with the X Font Server:

>   No, this is not the case.
>   It runs as "build" and that is all.

>   The problem is that the use of mm confuses the proc-permission system
> into thinking that the process is setuid. I wandered through this last
> year, when we first noticed this problem.

>   This seems to be due to how mm->dumpable is initalized.
> (see task_dumpable in fs/proc/base.c)
>   I tried to change it, but I was not successful. I can dig up my
> attempts, but they are on the list.

Oh, ok... this can be fixed, I guess, with these infos... I'll come back to 
this when I have time.

Actually, what I should do is to set the "mm->dumpable" flag to 1 inside 
mm/proc_mm.c (after mm_alloc(), it is 0). The situation is clear. However, to 
write a good patch, I want to study well the "mm->dumpable" flag use (when 
it's set, when not...) otherwise I could open a security hole (even because 
there are people using UML setuid to root, for the mlock() patch).

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Henrik Nordstrom]

On Mon, 4 Oct 2004, BlaisorBlade wrote:

> Actually, what I should do is to set the "mm->dumpable" flag to 1 inside
> mm/proc_mm.c (after mm_alloc(), it is 0). The situation is clear. However, to
> write a good patch, I want to study well the "mm->dumpable" flag use (when
> it's set, when not...) otherwise I could open a security hole (even because
> there are people using UML setuid to root, for the mlock() patch).

I don't think it is safe to set dumpable to 1 once it has become 0.

If you want to fix this you need to find secure ways to prevent it from 
becoming 0, or to add another parameter defining "security restricted" 
processes differently from dumpable.

Just some thoughts.

Regards
Henrik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "BlaisorBlade" == BlaisorBlade  <blaisorblade_spam@yahoo.it> writes:
    BlaisorBlade> you should convince top-level hackers on the
    BlaisorBlade> LKML. Quite frankly, I guess that they will say 'NO';
    BlaisorBlade> and they will add "Who ever said that SIGKILL always
    BlaisorBlade> works?". And if Al Viro reads your post, his answer
    BlaisorBlade> could be very bad (Al Viro is famous for the way he
    BlaisorBlade> flames newbie kernel hackers).

  How about if I get Dennis Ritchie to post this :-)

  I've filed numerous bugs in the 1980s against SCO and SunOS about
kill-9 failing to clear a process due to device issues, and every single
one was acknowledged as correct. (Not that SCO ever fixed many of them,
but they didn't disagree)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQWHRUoqHRg3pndX9AQFvUQQAsr0HpRGjXi22D15lG32ly0iij6XBR6oZ
qXIHAxckGtdam4hDeXbbYkZFC6Ph4x/ClStl4VWdXmPw6RM0aQzzZQw74j94pd2J
RCb8ShufEsLJrqzjFb5Z4kPoh3Vv8/LUFzNQNDg5bLADPiHVzxOfHa+znlSnfYGJ
JGkHk6uZy/4=
=Yc8N
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Monday 04 October 2004 22:25, Henrik Nordstrom wrote:
> On Mon, 4 Oct 2004, BlaisorBlade wrote:
> > Actually, what I should do is to set the "mm->dumpable" flag to 1 inside
> > mm/proc_mm.c (after mm_alloc(), it is 0). The situation is clear.
> > However, to write a good patch, I want to study well the "mm->dumpable"
> > flag use (when it's set, when not...) otherwise I could open a security
> > hole (even because there are people using UML setuid to root, for the
> > mlock() patch).
>
> I don't think it is safe to set dumpable to 1 once it has become 0.

I think you are overlooking something ... read the original mail. The problem 
is that for the userspace thread mm->dumpable is always 0, and this happens 
on every known SKAS3 patch revision. Simply nobody thought about this before 
now.

The field does not "become" 0. allocate_mm, or whatever, allocates the 
mm_struct, fills it with 0, and then initializes some basic fields. After 
fork and execve, the dumpable field is adjusted according to the needs (and 
can become 1).

Since opening /proc/mm is more or less like creating a new process (or even 
like forking), dumpable can become 1, following the general Linux rules. 

Actually, the current fork() code simply copies the dumpable flag with all the 
rest, and does not change it; this also makes a lot of sense, and I guess 
that open_proc_mm will just copy the current->mm->dumpable setting to the new 
mm.

However, that's a problem if a process using /proc/mm changes its setting of 
mm->dumpable (which happens on uid changes and with prctl). Does in that case 
the uid of the ptraced process change?

If needed, it could be reloaded on the new mm when using PROC_SWITCH_MM, but 
that is strange. Also, I don't understand why prctl() does not do any 
security check.

And anyway, I'm not rushing on this... I want to study the mainstream code and 
the ptrace exploit patch, before coding anything here.

> If you want to fix this you need to find secure ways to prevent it from
> becoming 0, or to add another parameter defining "security restricted"
> processes differently from dumpable.

Hmm, Alan Cox has been writing some changes to the dumpable flag (a sysctl 
option, I think).

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[Henrik Nordstrom]

On Tue, 5 Oct 2004, BlaisorBlade wrote:

> Since opening /proc/mm is more or less like creating a new process (or even
> like forking), dumpable can become 1, following the general Linux rules.

only if it was 1 for the process I think. If it was 0 for the process then 
there is a obvious risk that sensitive pages will get migrated to the new 
mm.

creating a new memory map within the process is not really the same as 
exec if I understand SKAS correctly. The two memory maps may be set to 
share a significant portion of pages including data pages, while on exec 
you are guaranteed the two memory maps are fully separate unless they 
cooperate via mmap or shm which both have access to.

If there is need to then it may be possible to add an argument indicating 
that the mm should be dumpable even if sanity checks says it should not, 
but I don't see very much need for this.

> However, that's a problem if a process using /proc/mm changes its 
> setting of mm->dumpable (which happens on uid changes and with prctl). 
> Does in that case the uid of the ptraced process change?

In such case the dumpable attribute needs to be cleared on all mm:s of 
that process. There is no easy way telling which memory maps may contain 
restricted pages on such change of the process status.

Regarding prctl, the running code can be assumed trusted here. The 
dumpable attribute is about preventing sensitive data from leaking outside 
of the process. If you circumvent this by setting dumpable to 1 you are 
assumed to know what you (and any libraries you use) do and assume all 
responsibility. It is only the running process code itself which can do 
this, the user can not force it externally from outside of the process

Regards
Henrik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Wednesday 06 October 2004 02:00, Henrik Nordstrom wrote:
> On Tue, 5 Oct 2004, BlaisorBlade wrote:
> > Since opening /proc/mm is more or less like creating a new process (or
> > even like forking), dumpable can become 1, following the general Linux
> > rules.
>
> only if it was 1 for the process I think. If it was 0 for the process then
> there is a obvious risk that sensitive pages will get migrated to the new
> mm.
Yes, I agree on this (even if I had not the "shared pages" problem in my 
picture of the problem).

> creating a new memory map within the process is not really the same as
> exec if I understand SKAS correctly. The two memory maps may be set to
> share a significant portion of pages including data pages, while on exec
> you are guaranteed the two memory maps are fully separate unless they
> cooperate via mmap or shm which both have access to.

In fact I was going to compare it to fork, not to exec, because what we do is 
more similar to creating a new mm and a new process, instead of replacing a 
process with another... and plus there is a lot of shared-memory, which is a 
problem.

> If there is need to then it may be possible to add an argument indicating
> that the mm should be dumpable even if sanity checks says it should not,
> but I don't see very much need for this.

I don't want to skip the sanity checks! They are currently skipped and 
dumpable is always 0. Stop. And the fact that we are safe (i.e. that dumpable 
is by default 0) seems to just be by a lucky accident, actually. Oh well.

> > However, that's a problem if a process using /proc/mm changes its
> > setting of mm->dumpable (which happens on uid changes and with prctl).
> > Does in that case the uid of the ptraced process change?

> In such case the dumpable attribute needs to be cleared on all mm:s of
> that process. There is no easy way telling which memory maps may contain
> restricted pages on such change of the process status.

Ok, in this case, this should be doable on PTRACE_SWITCH_MM. Anyway, the 
dumpable flag can become 1 again only with prctl(), so in that case things 
should be safe (or it is the application's fault).

> Regarding prctl, the running code can be assumed trusted here. The
> dumpable attribute is about preventing sensitive data from leaking outside
> of the process. If you circumvent this by setting dumpable to 1 you are
> assumed to know what you (and any libraries you use) do and assume all
> responsibility. It is only the running process code itself which can do
> this, the user can not force it externally from outside of the process

Ok, this is fine and clear.

Btw: I've also found the ptrace root exploit for 2.4.20. And I'm understanding 
the old problem.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] T-mode processes

[BlaisorBlade]

On Wednesday 06 October 2004 02:00, Henrik Nordstrom wrote:
> On Tue, 5 Oct 2004, BlaisorBlade wrote:
> > Since opening /proc/mm is more or less like creating a new process (or
> > even like forking), dumpable can become 1, following the general Linux
> > rules.
>
> only if it was 1 for the process I think.
These are the general Linux rules applied on fork.
> If it was 0 for the process then 
> there is a obvious risk that sensitive pages will get migrated to the new
> mm.

> creating a new memory map within the process is not really the same as
> exec if I understand SKAS correctly. The two memory maps may be set to
> share a significant portion of pages including data pages, 

> while on exec   
> you are guaranteed the two memory maps are fully separate unless they
> cooperate via mmap or shm which both have access to.

Hmmm - there is no difference between the two situations. We can expect UML 
creating shared mappings, but that is not entirely different from when two 
processes share memory via mmap. In both cases, they share data (even 
sensitive). Or better, since the file is unlinked, it's like when a parent 
and a child share data through mmap()'ing the same file descriptor.

> If there is need to then it may be possible to add an argument indicating
> that the mm should be dumpable even if sanity checks says it should not,
> but I don't see very much need for this.
No will to implement anything like this.
> > However, that's a problem if a process using /proc/mm changes its
> > setting of mm->dumpable (which happens on uid changes and with prctl).
> > Does in that case the uid of the ptraced process change?
>
> In such case the dumpable attribute needs to be cleared on all mm:s of
> that process. There is no easy way telling which memory maps may contain
> restricted pages on such change of the process status.
Yes, this is what I've implemented. I'm sending the patch for this just now 
(separately because it's via patch-scripts).

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel