Hi there,
I'm Stepan G. Chatalyan, and i think that I discovered a bug or design
flaw... and I don't know that it is provide from kernel...
Let's see:
(1) I mount /tmp with noexec,nosuid,nodev options
/dev/hda6 on /tmp type ext3 (rw,noexec,nosuid,nodev,relatime)
(2) I went to 'cd /tmp'`and I created a bash script, or another script
(perl, python, etc)... and chmod +x createdfile
script cointain:
#!/bin/bash
echo "Probe..."
(3) I tried to execut it with "./createdfile"
[kehcho@kehcho] [/tmp]$ ./createdfile
-bash: ./createdfile: /bin/bash: bad interpreter: Permission denied
(4) I tried to execute it, but pass to bash ". /tmp/createdfile"
[kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
Probe...
It is a kernel bug or I just report a another one?
BB
--
Regards
It looks to me like expected behavior using noexec mount option?
On Fri, Jan 22, 2010 at 12:05 PM, Stepan Chatalyan <[email protected]> wrote:
> Hi there,
>
> I'm Stepan G. Chatalyan, and i think that I discovered a bug or design
> flaw... and I don't know that it is provide from kernel...
>
> Let's see:
>
> (1) I mount /tmp with noexec,nosuid,nodev options
>
> /dev/hda6 on /tmp type ext3 (rw,noexec,nosuid,nodev,relatime)
>
> (2) I went to 'cd /tmp'`and I created a bash script, or another script
> (perl, python, etc)... and chmod +x createdfile
> script cointain:
>
> #!/bin/bash
> echo "Probe..."
>
> (3) I tried to execut it with "./createdfile"
> [kehcho@kehcho] [/tmp]$ ./createdfile
> -bash: ./createdfile: /bin/bash: bad interpreter: Permission denied
>
> (4) I tried to execute it, but pass to bash ". /tmp/createdfile"
>
> [kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
> Probe...
>
> It is a kernel bug or I just report a another one?
>
> BB
>
> --
> Regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Fri, Jan 22, 2010 at 02:05:50AM +0100, Stepan Chatalyan wrote:
> (1) I mount /tmp with noexec,nosuid,nodev options
> (4) I tried to execute it, but pass to bash ". /tmp/createdfile"
>
> [kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
> Probe...
>
> It is a kernel bug or I just report a another one?
What the hell does it have to do with the kernel? You've told shell
to open a text file, read it and interpret its contents line by line.
It had done as instructed. Moreover, bash /tmp/createdfile would work
just as fine. Neither of those would attempt to do execve() on the
file in question; you are just telling shell what to open and read.
Hey, buddy, this is not the right place to raise a user-space
question. But as for your question, you'd better to learn what the "."
means. "#!/bin/bash" is used to indicate in shell when executed, while
to be just a comment in the latter.
2010/1/22 Stepan Chatalyan <[email protected]>:
> Hi there,
>
> I'm Stepan G. Chatalyan, and i think that I discovered a bug or design
> flaw... and I don't know that it is provide from kernel...
>
> Let's see:
>
> (1) I mount /tmp with noexec,nosuid,nodev options
>
> /dev/hda6 on /tmp type ext3 (rw,noexec,nosuid,nodev,relatime)
>
> (2) I went to 'cd /tmp'`and I created a bash script, or another script
> (perl, python, etc)... and chmod +x createdfile
> script cointain:
>
> #!/bin/bash
> echo "Probe..."
>
> (3) I tried to execut it with "./createdfile"
> [kehcho@kehcho] [/tmp]$ ./createdfile
> -bash: ./createdfile: /bin/bash: bad interpreter: Permission denied
>
> (4) I tried to execute it, but pass to bash ". /tmp/createdfile"
>
> [kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
> Probe...
>
> It is a kernel bug or I just report a another one?
>
> BB
>
> --
> Regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Thursday 21 January 2010 09:00:15 pm Shu Wu wrote:
> Hey, buddy, this is not the right place to raise a user-space
> question. But as for your question, you'd better to learn what the "."
> means. "#!/bin/bash" is used to indicate in shell when executed, while
> to be just a comment in the latter.
>
> 2010/1/22 Stepan Chatalyan <[email protected]>:
> > Hi there,
> >
> > I'm Stepan G. Chatalyan, and i think that I discovered a bug or design
> > flaw... and I don't know that it is provide from kernel...
> >
> > Let's see:
> >
> > (1) I mount /tmp with noexec,nosuid,nodev options
> >
> > /dev/hda6 on /tmp type ext3 (rw,noexec,nosuid,nodev,relatime)
> >
> > (2) I went to 'cd /tmp'`and I created a bash script, or another script
> > (perl, python, etc)... and chmod +x createdfile
> > script cointain:
> >
> > #!/bin/bash
> > echo "Probe..."
> >
> > (3) I tried to execut it with "./createdfile"
> > [kehcho@kehcho] [/tmp]$ ./createdfile
> > -bash: ./createdfile: /bin/bash: bad interpreter: Permission denied
> >
> > (4) I tried to execute it, but pass to bash ". /tmp/createdfile"
> >
> > [kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
> > Probe...
> >
> > It is a kernel bug or I just report a another one?
This is not a bug at all. I'll just repeat Shu Wu's statement - learn what "."
actually does. Note: it is *NOT* the same as $(...) or `...` - and it is not
the same as directly executing a script.
DRH
On Fri, Jan 22, 2010 at 10:00 AM, Shu Wu <[email protected]> wrote:
> Hey, buddy, this is not the right place to raise a user-space
> question. But as for your question, you'd better to learn what the "."
> means. "#!/bin/bash" is used to indicate in shell when executed, while
> to be just a comment in the latter.
>
"." equals to "source", which means sourcing a file, it is the shell
which he is using does this, which is always available by executing
"echo $0" from command line. Yes, shebang is used when executing.
> (3) I tried to execut it with "./createdfile"
> [kehcho@kehcho] [/tmp]$ ./createdfile
> -bash: ./createdfile: /bin/bash: bad interpreter: Permission denied
The kernel noexec blocks execution of binaries from the file system. It's
not really a 'security' model so much as a useful historic way of
stopping people running wrong things by accident, and over NFS and the
like of stopping people trying to run binaries for the wrong machine
> (4) I tried to execute it, but pass to bash ". /tmp/createdfile"
>
> [kehcho@tornadowt] [/tmp]$ . /tmp/createdfile
> Probe...
>
> It is a kernel bug or I just report a another one?
Then bash loads the file and interprets the commands - not the kernel.
Data is data - there is no real distinction between "instructions" to
execute and "data files" in computing.
The "nosuid" bit is different. Only the kernel has the power to grant
suid status so while you could run a noexec program by hand loading it
you couldn't make it run setuid that way.