Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why bother with argv[0]?

wietzebeukema.nl

Post reply on HN
Print view View original

31–40 of 277 posts

Re: Why bother with argv[0]?

#31

Post by dividuum »

lanstin wrote: post #26

This article seems to be an example of how some common security practices are kind of surface level. If you want to limit what a box can access on the network, do it in the network. Why is security looking for bad urls in the argv; if you know they are bad just block them? Or better yet if they aren't good, don't allow them. And if you want to know what a process is doing, ask the kernel to log its syscalls. If you t…

Seriously: Their reason is basically "argv[0] is bad because security snake oil software is garbage":

1) Oh no, the only protection is looking at argv[0]. What kind of clown software is that? Software that notably runs on an already compromised system..

2) No need for argv[0] to fool software that concats argv values with spaces: just run 'curl -o "test.txt |grep" 1.1.1.1'

3) A long argument messes up telemetry? Let's hope that bucket doesn't have more holes.

Re: Why bother with argv[0]?

#32

Post by travisgriggs »

> “Should a program be allowed to behave differently based on its name?”

I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.

Re: Why bother with argv[0]?

#33

Post by omphaloskeptic »

Also, on POSIX systems, exec-ing a program with argv[0] starting with ‘-‘ will have it start as a login shell, which is a whole rabbit hole of its own. I’m sure it’s within the security model (and the linked article doesn’t really discuss the concept of OS security models), but it’s still a pretty big shift in behaviour just from adding a character to the argv[0] value

Re: Why bother with argv[0]?

#34

Post by duped »

cubist_castle wrote: post #11
avidiax wrote: post #4

It is sometimes used to allow one binary to be the symlink target of hundreds of commands. Android does this for most common shell commands. Toybox and busybox are examples of such implementations. https://github.com/landley/toybox https://en.m.wikipedia.org/wiki/BusyBox

I just learned that rustup/rustc/cargo etc. work like this too. I couldn't understand why the gentoo formula was symlinking the same binary to a bunch of aliases.

clang does this too.

Re: Why bother with argv[0]?

#35

Post by theamk »

That's a weird take against argv[0] - all arguments are: "goes against modern design principles" and "can confuse programs which use argv[0] when they wanted "exec" instead"

For the former, I don't see how this goes against modern principles - in presence of symlinks, it is pretty reasonable to want to know both "how was this program called", as well as "what's the actual executable we ended up with". And this does more than just giving multiple names to same program - for example python uses argv[0] to tell if it's inside virtualenv and adjust search paths accordingly. This makes it appear like there are multiple python installs on system, with no extra disk space taken.

For the latter, yes, programs can have bugs and OSes can have non-obvious semantics, and if you are security software, it's very important to be aware about them. I would not mark "argv[0]" as something especially bad from security perspective. All the author's examples would still be possible in hypothetical world where argv[0] is set by system - as nothing stops user from creating a symlink in temporary dir with deceiving name (spaces and quotes are OK in filenames!) and exec'ing it directly. Instead, fix your security software so it quotes argv values?

Re: Why bother with argv[0]?

#36

Post by MPSimmons »

travisgriggs wrote: post #32

> “Should a program be allowed to behave differently based on its name?” I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.

If not, then busybox is going to need to change a TON

Re: Why bother with argv[0]?

#37

Post by shermantanktop »

travisgriggs wrote: post #32

> “Should a program be allowed to behave differently based on its name?” I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.

It’s the equivalent of the HTTP Host header, with similar utility. But I agree with the author that an OS provided trustable structure is a much better way.

Re: Why bother with argv[0]?

#38

Post by shermantanktop »

dividuum wrote: post #31
lanstin wrote: post #26

This article seems to be an example of how some common security practices are kind of surface level. If you want to limit what a box can access on the network, do it in the network. Why is security looking for bad urls in the argv; if you know they are bad just block them? Or better yet if they aren't good, don't allow them. And if you want to know what a process is doing, ask the kernel to log its syscalls. If you t…

Seriously: Their reason is basically "argv[0] is bad because security snake oil software is garbage": 1) Oh no, the only protection is looking at argv[0]. What kind of clown software is that? Software that notably runs on an already compromised system.. 2) No need for argv[0] to fool software that concats argv values with spaces: just run 'curl -o "test.txt |grep" 1.1.1.1' 3) A long argument messes up telemetry? Let'…

These are all very realistic examples. Should they happen? No, but reality is messy and imperfect. The crappy software you describe would not exist if there were great solutions in this space.

Re: Why bother with argv[0]?

#39

Post by dataflow »

travisgriggs wrote: post #32

> “Should a program be allowed to behave differently based on its name?” I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.

> I don’t see why not. It’s allowed to behave differently based on the arguments that follow it.

That's missing the point, I think.

The real question here is, is the name of a program really an argument to the program, from the user's perspective? I certainly don't blame users that disagree. It's more difficult for them to change argv[0], and the fact that this is possible is not necessarily obvious to them, nor to their users.

If it helps, think of it like this: imagine the file timestamp was similarly passed as argv[-1]. And that the file inode number was passed as argv[-2]. Would it make sense to change behavior on those too?

Post reply on HN