You are not logged in.

#1 2009-05-19 05:34:31

Xyne
Administrator/PM
Registered: 2008-08-03
Posts: 6,963
Website

How can you deny bash system access when sourcing a file?

I'm having another one of my "Linux noob" moments. This is probably easy to answer for the experienced bashers here.


I need a bash function to extract data from a PKGBUILD for use in other scripts. I want to write it in such a way that there is no significant risk when checking PKGBUILDs from possibly untrusted sources. It would be unreasonable to request the user to manually inspect every PKGBUILD when only extracting information (i.e. not building the package) and when dealing with many PKGBUILDs.

The function itself is very simple in the unsafe version:

for ARG in $@; do
  source "$ARG"
  echo "$pkgname $pkgver $pkgrel"
done

The reason that I want to source the file is to catch variable changes within the script (obviously missing the build function, but there are some that change outside of it). Parsing the file externally is likely to miss some changes.

How can I safely source the PKGBUILD? Ideally I want to completely limit access to the system, specifically the users home directory. Is there a way to do this as a user without write permissions? Is this what the "nobody" user is for?

I've considered using chroot but that appears to need root privileges. I want to avoid sudo.

Thanks.

Last edited by Xyne (2009-05-19 11:09:25)


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

#2 2009-05-19 06:07:27

djgera
Developer
From: Buenos Aires - Argentina
Registered: 2008-12-24
Posts: 723
Website

Re: How can you deny bash system access when sourcing a file?

Hi see "RESTRICTED SHELL" in the manpage of bash, this can help you wink

Offline

#3 2009-05-19 10:52:38

Xyne
Administrator/PM
Registered: 2008-08-03
Posts: 6,963
Website

Re: How can you deny bash system access when sourcing a file?

*smacks head for not checking the bash man page*

Thanks djgera, that seems to be exactly what I need.

*edit*
I spoke too soon. I can still delete files outside of the directory, e.g. this deletes the file "test.txt" in my home dir:

$mktemp -d /tmp/foo-XXXX
/tmp/foo-kzkN

$ cd /tmp/foo-kzkN/

$ bash -r -c 'rm ~/test.txt'

I misread the man page at first and thought that it would block all access to files specified with a slash. While the restricted shell is useful, it still wouldn't prevent a file from wiping the users home directory.

Is there a way to run bash as a restricted user, i.e. one who has absolutely no write permissions to any existing files on the system?

Last edited by Xyne (2009-05-19 11:27:34)


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

#4 2009-05-19 16:13:23

ataraxia
Member
From: Pittsburgh
Registered: 2007-05-06
Posts: 1,553

Re: How can you deny bash system access when sourcing a file?

Run it as a sandbox user, i.e., "nobody".

Offline

#5 2009-05-19 16:36:40

djgera
Developer
From: Buenos Aires - Argentina
Registered: 2008-12-24
Posts: 723
Website

Re: How can you deny bash system access when sourcing a file?

rm is executed because is in the PATH, just unset PATH wink or... unset all env wink

Offline

#6 2009-05-19 16:42:44

djgera
Developer
From: Buenos Aires - Argentina
Registered: 2008-12-24
Posts: 723
Website

Re: How can you deny bash system access when sourcing a file?

also can disable some bash builtins... "enable -n kill" , etc, etc. wink You have the control smile

Offline

#7 2009-05-19 17:03:09

hbekel
Member
Registered: 2008-10-04
Posts: 311

Re: How can you deny bash system access when sourcing a file?

Well, unsetting the PATH seems a good idea, but what if the pkgbuild contains sth like this:

pkgver=$(uname -r)

or any similar manner of dynamically generating one of the variables Xyne's interested in by using a command in a subshell? While the following works (i.e. fails as it should):

~$> OLDPATH=$PATH;export PATH="";/bin/bash -r -c 'foo=$(rm foo);foo=$(/bin/rm foo)';export PATH=$OLDPATH
/bin/bash: rm: No such file or directory
/bin/bash: /bin/rm: restricted: cannot specify `/' in command names

any legitimate use of command substitution will fail as well. Not to mention redirection, which is disabled in a restricted shell as well.

And yes, disabling (possibly) malicious bash builtins may be done as well, but it will fail as well if they are used in a legitimate way.

Using "nobody" also relies on the assumption that the user's files aren't world-writable. I think the only safe solution is using a chroot after all, but maybe I'm missing something here.

Offline

Board footer

Powered by FluxBB