nonroot umount

nonroot umount

[Marcos Diez]

In a Unix desktop system automount is very practical for CDROMs, digital
cameras, USB flash drives and any other type of removable media.
But it is annoying to the unprivileged user to wait the timeout to
remove the media.

Since it is insecure to allow the user to do a "killall -s SIGUSR1
automount", I wrote a program that does exactly (and only) that. Of
course it must be suid root, but it makes life much easier. I double
verified that there are no buffer overflows and I believe it's safe. The
program is not interactive, so a malicious user can't do much with it
anyway.

It gets the PIDs from instances of automount by parsing /proc/mounts
It would be nice if it could be added to the autofs distribution.


http://boby.unitron.com.br/%7Emarcos/umounter.c


To compile:

gcc -O3 -ansi -Wall -pedantic umounter.c -o umounter

To install:
cp umounter /usr/local/bin && chmod 4711 /usr/local/bin/umounter

To use:

./umounter
or
./umounter --verbose
(show the signaled PIDs )


Thanks

-- 
Marcos Diez
+49 178 507 9577
Skype: aboboraabobora

Re: nonroot umount

[Peter Staubach]

Marcos Diez wrote:

>In a Unix desktop system automount is very practical for CDROMs, digital
>cameras, USB flash drives and any other type of removable media.
>But it is annoying to the unprivileged user to wait the timeout to
>remove the media.
>
>Since it is insecure to allow the user to do a "killall -s SIGUSR1
>automount", I wrote a program that does exactly (and only) that. Of
>course it must be suid root, but it makes life much easier. I double
>verified that there are no buffer overflows and I believe it's safe. The
>program is not interactive, so a malicious user can't do much with it
>anyway.
>
>It gets the PIDs from instances of automount by parsing /proc/mounts
>It would be nice if it could be added to the autofs distribution.
>
>
>http://boby.unitron.com.br/%7Emarcos/umounter.c
>
>
>To compile:
>
>gcc -O3 -ansi -Wall -pedantic umounter.c -o umounter
>
>To install:
>cp umounter /usr/local/bin && chmod 4711 /usr/local/bin/umounter
>
>To use:
>
>./umounter
>or
>./umounter --verbose
>(show the signaled PIDs )
>

It seems to me that a better architected solution might be to tie in
the automounter with the eject(1) sort of command.

It is not good for a user to have to know that he needs to zing the
automounter in order to remove his media.

    Thanx...

       ps

Re: nonroot umount

[Jeff Moyer]

==> Regarding Re: [autofs] nonroot umount; Peter Staubach <staubach@redhat.com> adds:

staubach> Marcos Diez wrote:
>> In a Unix desktop system automount is very practical for CDROMs, digital
>> cameras, USB flash drives and any other type of removable media.
>> But it is annoying to the unprivileged user to wait the timeout to
>> remove the media.
>> 
>> Since it is insecure to allow the user to do a "killall -s SIGUSR1
>> automount", I wrote a program that does exactly (and only) that. Of
>> course it must be suid root, but it makes life much easier. I double
>> verified that there are no buffer overflows and I believe it's safe. The
>> program is not interactive, so a malicious user can't do much with it
>> anyway.
>> 
>> It gets the PIDs from instances of automount by parsing /proc/mounts
>> It would be nice if it could be added to the autofs distribution.
>> 
>> 
>> http://boby.unitron.com.br/%7Emarcos/umounter.c
>> 
>> 
>> To compile:
>> 
>> gcc -O3 -ansi -Wall -pedantic umounter.c -o umounter
>> 
>> To install:
>> cp umounter /usr/local/bin && chmod 4711 /usr/local/bin/umounter
>> 
>> To use:
>> 
>> ./umounter
>> or
>> ./umounter --verbose
>> (show the signaled PIDs )
>> 

staubach> It seems to me that a better architected solution might be to tie in
staubach> the automounter with the eject(1) sort of command.

staubach> It is not good for a user to have to know that he needs to zing the
staubach> automounter in order to remove his media.

What "desktop" system are we talking about?  If you're using hal/udev, then
they have a much nicer mechanism for handling such things.  Autofs isn't
really a good fit for removable media, in my experience.

-Jeff

Re: nonroot umount

[Peter Staubach]

Jeff Moyer wrote:

>==> Regarding Re: [autofs] nonroot umount; Peter Staubach <staubach@redhat.com> adds:
>
>staubach> Marcos Diez wrote:
>  
>
>>>In a Unix desktop system automount is very practical for CDROMs, digital
>>>cameras, USB flash drives and any other type of removable media.
>>>But it is annoying to the unprivileged user to wait the timeout to
>>>remove the media.
>>>
>>>Since it is insecure to allow the user to do a "killall -s SIGUSR1
>>>automount", I wrote a program that does exactly (and only) that. Of
>>>course it must be suid root, but it makes life much easier. I double
>>>verified that there are no buffer overflows and I believe it's safe. The
>>>program is not interactive, so a malicious user can't do much with it
>>>anyway.
>>>
>>>It gets the PIDs from instances of automount by parsing /proc/mounts
>>>It would be nice if it could be added to the autofs distribution.
>>>
>>>
>>>http://boby.unitron.com.br/%7Emarcos/umounter.c
>>>
>>>
>>>To compile:
>>>
>>>gcc -O3 -ansi -Wall -pedantic umounter.c -o umounter
>>>
>>>To install:
>>>cp umounter /usr/local/bin && chmod 4711 /usr/local/bin/umounter
>>>
>>>To use:
>>>
>>>./umounter
>>>or
>>>./umounter --verbose
>>>(show the signaled PIDs )
>>>
>>>      
>>>
>
>staubach> It seems to me that a better architected solution might be to tie in
>staubach> the automounter with the eject(1) sort of command.
>
>staubach> It is not good for a user to have to know that he needs to zing the
>staubach> automounter in order to remove his media.
>
>What "desktop" system are we talking about?  If you're using hal/udev, then
>they have a much nicer mechanism for handling such things.  Autofs isn't
>really a good fit for removable media, in my experience.
>

Cool!

My only objection was building tools to utilize automount specific
implementation details.  That's just wrong.

Perhaps we need to redirect Marcos Diez to better functionality to
solve his problems...  :-)

    Thanx...

       ps

Re: nonroot umount

[Jim Dennis]

 

On Date: Tue, 11 Jul 2006 08:39:01 -0400
Peter Staubach <staubach@redhat.com> wrote (in response to Marcos Diez
<marcos@unitron.com.br>):

> Marcos Diez wrote:

>> In a Unix desktop system automount is very practical for CDROMs, 
>> digital cameras, USB flash drives and any other type of removable
media.
>> But it is annoying to the unprivileged user to wait the timeout to 
>> remove the media.

> It seems to me that a better architected solution might be to tie in
the automounter with the eject(1) sort of command.

> It is not good for a user to have to know that he needs to zing the
automounter in order to remove his media.

>    Thanx...
>       ps

 So, perhaps we could send a patch to the maintainer of the eject
utility.  It could detect if the target is
 under an autofs and use this code in place of the ioctl() that it would
normally send to a CD-ROM or similar
 device.

 On my OpenSuSE system eject is already marked SUID/root, though it
doesn't seem the be the case for my RHEL4
 system nor on my Debian system.

 As usual I'd limit the risk of another SUID/root binary by marking the
executable mode 4550 and associating
 it with some relevant group (such as "console").  Thus only processes
running in the specified group can attempt
 to exploit any vulnerabilities in it.

 Question: how would one programmatically detect that a particular mount
point is being managed by an autofs process?

JDennis

Re: nonroot umount

[Jeff Moyer]

==> Regarding Re: [autofs] nonroot umount; "Jim Dennis" <jdennis@cadence.com> adds:

jdennis> On Date: Tue, 11 Jul 2006 08:39:01 -0400
jdennis> Peter Staubach <staubach@redhat.com> wrote (in response to Marcos Diez
jdennis> <marcos@unitron.com.br>):

>> Marcos Diez wrote:

>>> In a Unix desktop system automount is very practical for CDROMs, 
>>> digital cameras, USB flash drives and any other type of removable
jdennis> media.
>>> But it is annoying to the unprivileged user to wait the timeout to 
>>> remove the media.

>> It seems to me that a better architected solution might be to tie in
jdennis> the automounter with the eject(1) sort of command.

>> It is not good for a user to have to know that he needs to zing the
jdennis> automounter in order to remove his media.

>> Thanx...
>> ps

jdennis>  So, perhaps we could send a patch to the maintainer of the eject
jdennis> utility.  It could detect if the target is
jdennis>  under an autofs and use this code in place of the ioctl() that it would
jdennis> normally send to a CD-ROM or similar
jdennis>  device.

jdennis>  On my OpenSuSE system eject is already marked SUID/root, though it
jdennis> doesn't seem the be the case for my RHEL4
jdennis>  system nor on my Debian system.

jdennis>  As usual I'd limit the risk of another SUID/root binary by marking the
jdennis> executable mode 4550 and associating
jdennis>  it with some relevant group (such as "console").  Thus only processes
jdennis> running in the specified group can attempt
jdennis>  to exploit any vulnerabilities in it.

jdennis>  Question: how would one programmatically detect that a particular
jdennis> mount point is being managed by an autofs process?

I simply don't like this idea.  ;)  As I mentioned before, there are better
mechanisms to deal with removable media.

If, however, you insist on using the automounter for this, then why not
specify a short timeout for removable media?  Put all forms of removable
media in the same map, and use --timeout=1 or 5, or 10, whatever suits
you.  Would that be an acceptable solution?

-Jeff