allow empty --protocol= list

[vn971]

Could an empty protocol list be allowed for firejail?
Like this: firejail --noprofile --protocol=
I think it may make sense in some scenarions. If it's not too difficult, please add such an ability?

(Sorry, I don't feel myself confident with C, therefore I can only raise issues & make some tests.. No code changes since I'd probably leak something or worse.)

[netblue30]

I'll bring a fix in this week, thanks!

[Fred-Barclay]

I'm afraid I'm in the dark here (which is my fault) and I can't quite figure out what this would accomplish. Would --protocol= be the same as --protocol=* i.e. would it allow all protocols (unix, inet, inet6...)? In which case I would suggest either --protocol or (preferably) --protocol=all as the syntax. To me at any rate, --protocol= looks like it's missing an argument on the end. 😃

Or would it deny access to any protocols? In which case, why use it? Wouldn't the absence of the protocol filter, in and of itself deny access to the filtered protocols?

Or am I missing the point entirely?

Like I said, I don't mean to indicate that I think this is a bad idea in any way; I just can't quite figure out what it does.

[vn971]

Hi @Fred-Barclay, by --protocol= I mean an empty set of allowed protocols. Same as an empty set in Math, or [] as empty arrays in programming.

An empty protocol list means the application cannot use unix sockets, inet interfaces and so on. But it still has access to the filesystem, so it can be a perfectly fine CLI/terminal program.

I guess @netblue30 will decide for naming. --protocol=none could work for some users. I'm perfectly fine with --protocol= because it matches my expectations as a programmer.

[Fred-Barclay]

Thanks @vn971
Like you, I'm not very confident with C (though I'm practising!) so I'm not really able to dig into the source code to understand these things. 😉
What would be the difference between this (which seems to basically be --protocol=none, am I correct?) and simply not having a protocol filter at all? Wouldn't the lack of a protocol argument deny access to the unix sockets, inet interfaces, and so on?

[vn971]

@Fred-Barclay I think it can be the whitelist/blacklist story that is confusing you. The --protocol directive is whitelist, not blacklist. And the absence of --protocol means to allow everything there is. If you think about it, it really is a little bit strange (at least semantically). --protocol= and the absence of a --protocol directive having the opposite meaning.

It's probably because of the history of firejail and that it tries to be "simple" for end users, therefore favoring "blacklisting" instead of "whitelisting". So adding new directives makes the container boundaries stronger, and some of the directives are whitelist-like.

[Fred-Barclay]

Aha, that does make more sense! Thanks, mate.

In that case, might I suggest using the syntax --protocol=none to minimise confusion and make its purpose clear?

[netblue30]

Yes, it will be --protocol=none, I'll have a fix in this week.

[vn971]

@netblue30 ping :)

[chiraag-nataraj]

I might try working on this, since I don't think it's in yet.

[chiraag-nataraj]

Oh right...I tried working on this a while back and couldn't really figure out how to safely do it... @netblue30 can you take care of this? 🙂

[rusty-snake]

protocol unix returns EOPNOTSUPP for every call to socket(2) except for socket(AF_UNIX, ...). Therefore would an empty protocol return EOPNOTSUPP for every call to socket(2) (without exceptions).

The only difference between seccomp socket and an empty protocol is that seccomp defaults to EPERM (and does what ever is specified in seccomp-error-action if set) while protocol always returns EOPNOTSUPP.

I'd suggest to close where as wontfix as the difference is so small and the only use case I can see are cli programs which do not need any sockets.

(In that case update pngquant.profile)