Hello,

(It's been an exceedingly long time since I last posted here. Happy to be back)

I've written my first Linux set-user-id-root program (let's call it foo-bin)

foo-bin is suid-root because:
1) foo-bin is supposed to be run by an unprivileged user,
2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

I didn't want *every* unprivileged user to be able to run foo-bin.
Only user 12345 is allowed to run foo-bin.

So I just added trivial code at the start of foo-bin:

if (getuid() != 12345)
die("Bad credentials");

My understanding is that, for an executable with the suid-root bit set,
the process's effective-user-id and saved-user-id will be 0 (root) while the
real-user-id (returned by getuid) will be that of the user running the program.

Thus my two-line "fix" seemed (seems?) like a perfect solution...
Yet, I didn't find anyone suggesting it on the interwebz, so I figured
it's just too simple to be correct.

I know there are things like dynamic library preloading that might allow
one to change getuid() to a no-op. (Though I'm aware that Linux ignores
dynamic library preloading for suid-root, probably for that reason.)

Could you point out how/why the proposed solution breaks/falls apart?

There's a different approach that would also work:
1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

Thus:
1) "random" normal users are not allowed to run foo-bin
2) user12345 is the only unprivileged user allowed to run foo-bin

Perhaps this solution is safer/better than my first solution?

Happy to read all your comments ;)

Regards.

Noob <root@127.0.0.1> writes:

> I've written my first Linux set-user-id-root program (let's call it foo-bin)
>
> foo-bin is suid-root because:
> 1) foo-bin is supposed to be run by an unprivileged user,
> 2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)
>
> I didn't want *every* unprivileged user to be able to run foo-bin.
> Only user 12345 is allowed to run foo-bin.
>
> So I just added trivial code at the start of foo-bin:
>
> if (getuid() != 12345)
> die("Bad credentials");

Generally, this sort of thing is done using sudo rather than hard-wiring
UIDs into source code. That sets my (code) teeth on edge!

--
Ben.

In article <sljmug$8di$2@dont-email.me>, Noob <root@127.0.0.1> wrote:
....
>There's a different approach that would also work:
>1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
>2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

My first (and best) thought was to do it via grops. Seems tailor-made for
this.

I'd create a new group (Say, foo-bin-users) and add your user to that
group. This makes it easy to add others in the future.

--
The single most important statistic in the US today - the one that explains all the
others - is this: 63 million people thought it was a good idea to vote for this clown
(and will probably do so again). Everything else is secondary to that. Everything else
could be fixed if we can revert this one statistic. Nothing can be fixed until we do.

On Sat, 30 Oct 2021 17:04:48 +0200
Noob <root@127.0.0.1> wrote:

> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

Don't you mean 4640? 0644 is typical for binaries. You're removing
world access and adding set-user-ID.

--jkl

In article <20211030170846.ef437b362217cf4a4614936e@speakeasy.net>,
James K. Lowden <jklowden@speakeasy.net> wrote:
>On Sat, 30 Oct 2021 17:04:48 +0200
>Noob <root@127.0.0.1> wrote:
>
>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
>
>Don't you mean 4640? 0644 is typical for binaries. You're removing
>world access and adding set-user-ID.

No. 755 is normal for executable files. You could get away with 711.

Actually, a habit I got into lomg ago, which has served me well over the
years, is to do: chmod 4711 ...

whenever I want to make something setuid (root).

So, if you're going to do the "group thing", it would be 4710.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seriously

"James K. Lowden" <jklowden@speakeasy.net> writes:
> On Sat, 30 Oct 2021 17:04:48 +0200
> Noob <root@127.0.0.1> wrote:
>
>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
>
> Don't you mean 4640? 0644 is typical for binaries. You're removing
> world access and adding set-user-ID.

Hmm? 4640 means no execute permission for anyone.

And since the original requirement was to allow only one *user*
to execute it, I'm not sure why everyone is talking about group
permissions. I'd make it 4700 or 4500 and set its ownership to
the one user who's allowed to execute it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 30/10/2021 23:20, Keith Thompson wrote:

> "James K. Lowden" writes:
>>
>> Noob wrote:
>>
>>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>>
>> Don't you mean 4640? 0644 is typical for binaries. You're removing
>> world access and adding set-user-ID.
>
> Hmm? 4640 means no execute permission for anyone.
>
> And since the original requirement was to allow only one *user*
> to execute it, I'm not sure why everyone is talking about group
> permissions. I'd make it 4700 or 4500 and set its ownership to
> the one user who's allowed to execute it.

Original requirement was to allow only one user to execute foo-bin *as root*

Therefore, foo-bin must be owned by root :)

Regards.

On 30/10/2021 22:37, Kenny McCormack wrote:

> In article <sljmug$8di$2@dont-email.me>, Noob wrote:
> ...
>> There's a different approach that would also work:
>> 1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
> My first (and best) thought was to do it via grops. Seems tailor-made for
> this.

s/grops/groups ? (I first parsed that as "grope", then gr_ops)

If groups, then you are agreeing with me, right?

> I'd create a new group (Say, foo-bin-users) and add your user to that
> group. This makes it easy to add others in the future.

I understand your point.

Regards.

On 30/10/2021 23:08, James K. Lowden wrote:

> Noob wrote:
>
>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
> Don't you mean 4640? 0644 is typical for binaries. You're removing
> world access and adding set-user-ID.

Your suggestion must be a typo/thinko?

Execute bit is 1. So none of 6,4,0 have the execute bit set.
Which is a problem for an executable :)

Regards.

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <sljmug$8di$2@dont-email.me>, Noob <root@127.0.0.1> wrote:
> ...
>>There's a different approach that would also work:
>>1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
>>2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
> My first (and best) thought was to do it via grops. Seems tailor-made for
> this.
>
> I'd create a new group (Say, foo-bin-users) and add your user to that
> group. This makes it easy to add others in the future.

That was what I thought too, then I realized may be better
to not bother with getuid(2) getgid(2) and just do:

# chgrp foo-bin
# chmod 750 foo-bin

Then it is not tied to a specific hard-coded ID/Group
and no setgid needed

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On Sat, 30 Oct 2021 23:51:28 +0200
Noob <root@127.0.0.1> wrote:

> > Don't you mean 4640? 0644 is typical for binaries. You're removing
> > world access and adding set-user-ID.
>
> Your suggestion must be a typo/thinko?

Yah. More coffee and less scotch, I guess. Or the opposite.

--jkl

Noob <root@127.0.0.1> writes:
> On 30/10/2021 23:20, Keith Thompson wrote:
>> "James K. Lowden" writes:
>>> Noob wrote:
>>>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>>>
>>> Don't you mean 4640? 0644 is typical for binaries. You're removing
>>> world access and adding set-user-ID.
>>
>> Hmm? 4640 means no execute permission for anyone.
>>
>> And since the original requirement was to allow only one *user*
>> to execute it, I'm not sure why everyone is talking about group
>> permissions. I'd make it 4700 or 4500 and set its ownership to
>> the one user who's allowed to execute it.
>
> Original requirement was to allow only one user to execute foo-bin *as root*
>
> Therefore, foo-bin must be owned by root :)

Oops, you're right.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 31/10/2021 01:23, John McCue wrote:

> Kenny McCormack wrote:
>
>> Noob wrote:
>>
>>> There's a different approach that would also work:
>>> 1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
>>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>>
>> My first (and best) thought was to do it via grops. Seems tailor-made for
>> this.
>>
>> I'd create a new group (Say, foo-bin-users) and add your user to that
>> group. This makes it easy to add others in the future.
>
> That was what I thought too, then I realized may be better
> to not bother with getuid(2) getgid(2) and just do:
>
> # chgrp foo-bin
> # chmod 750 foo-bin
>
> Then it is not tied to a specific hard-coded ID/Group
> and no setgid needed

Hello John,

I'm not sure I understand the specifics of your suggestion.
(And how it differs from Kenny's and my own second solution?)

(In solution #1, I used getuid.
In solution #2, I used "regular" Unix permissions.)

In your proposed solution,
What group does foo-bin belong to? (chgrp GROUP FILE)
Also, you dropped the set-user-id bit, this cannot work.

Regards.

On 30/10/2021 21:52, Ben Bacarisse wrote:

> Noob writes:
>
>> I've written my first Linux set-user-id-root program (let's call it foo-bin)
>>
>> foo-bin is suid-root because:
>> 1) foo-bin is supposed to be run by an unprivileged user,
>> 2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)
>>
>> I didn't want *every* unprivileged user to be able to run foo-bin.
>> Only user 12345 is allowed to run foo-bin.
>>
>> So I just added trivial code at the start of foo-bin:
>>
>> if (getuid() != 12345)
>> die("Bad credentials");
>
> Generally, this sort of thing is done using sudo rather than hard-wiring
> UIDs into source code. That sets my (code) teeth on edge!

Indeed, my solution above doesn't feel "right", I'll grant you that.

(It's worth noting that I work on an embedded system, where there are no
"real" users. User IDs are just used to isolate binaries from each other.)

In your solution, how would your sudo suggestion work?
You would add user12345 to the sudoers group?
But then user12345 could do anything that root can.
I want user12345 to be able to run foo-bin as root, nothing more.

Do you see any security issue with my solution #1?
I'll adopt solution #2 in production, but I wanted to hear people's opinion
as to why solution #1 fails ;)

Regards.

Noob <root@127.0.0.1> writes:
> In your solution, how would your sudo suggestion work?
> You would add user12345 to the sudoers group?
> But then user12345 could do anything that root can.
> I want user12345 to be able to run foo-bin as root, nothing more.

sudo can supposedly restrict privileged execution of certain commands to
certain users. (I say “supposedly” due to its rather sad CVE record.)

> Do you see any security issue with my solution #1?
> I'll adopt solution #2 in production, but I wanted to hear people's opinion
> as to why solution #1 fails ;)

It works in its environment, but it’s not robust against changes to that
environment, e.g. if it gets moved to a different system, or the system
gets reinstalled for some reason, or the rules change about which
user(s) should be able to execute it. Whether relevant changes to its
environment are likely is not something anyone else can predict for you.

--
https://www.greenend.org.uk/rjk/

Noob <root@127.0.0.1> wrote:
> On 31/10/2021 01:23, John McCue wrote:
>
>> Kenny McCormack wrote:
>>
>>> Noob wrote:
<snip>

>> That was what I thought too, then I realized may be better
>> to not bother with getuid(2) getgid(2) and just do:
>>
>> # chgrp foo-bin
>> # chmod 750 foo-bin
>>
>> Then it is not tied to a specific hard-coded ID/Group
>> and no setgid needed
>
> Hello John,
>
> I'm not sure I understand the specifics of your suggestion.
> (And how it differs from Kenny's and my own second solution?)
>
> (In solution #1, I used getuid.
> In solution #2, I used "regular" Unix permissions.)
>
> In your proposed solution,
> What group does foo-bin belong to? (chgrp GROUP FILE)
> Also, you dropped the set-user-id bit, this cannot work.

foo-bin would be 750:
-rwxr-x--- 1 root foo-bin .... foo-bin

then only User IDs in group foo-bin would have execute
access to it. You would need to create a group named
foo-bin (or whatever you would like to use) and add users
you want to execute binary foo-bin to that new group.

You can even get fancier if you system supports ACLs.

https://en.wikipedia.org/wiki/Access-control_list

but the end result is you can avoid using a set[gu]id
and hardcoding a check in the binary.

>
> Regards.

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

Noob <root@127.0.0.1> writes:
> I've written my first Linux set-user-id-root program (let's call it foo-bin)
>
> foo-bin is suid-root because:
> 1) foo-bin is supposed to be run by an unprivileged user,
> 2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

[...]

> There's a different approach that would also work:
> 1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

That's what I usually do as a decision re: who is or isn't allowed to
run this falls into the realm of administrative policy which shouldn't
be hardcoded (IMHO).

Also, 4710 is sufficient: It's not necessary to read a file in order to
execute it, ie, while the kernel obviously has to, processes running
with the uid of a user supposed to be allowed to execute a file don't
need to read its contents.

On 31/10/2021 14:48, John McCue wrote:

> Noob wrote:
>
>> (In solution #1, I used getuid.
>> In solution #2, I used "regular" Unix permissions.)
>>
>> In your proposed solution,
>> What group does foo-bin belong to? (chgrp GROUP FILE)
>> Also, you dropped the set-user-id bit, this cannot work.
>
> foo-bin would be 750:
> -rwxr-x--- 1 root foo-bin .... foo-bin
>
> then only User IDs in group foo-bin would have execute
> access to it. You would need to create a group named
> foo-bin (or whatever you would like to use) and add users
> you want to execute binary foo-bin to that new group.

As far as I can tell, your suggestion is the same as Kenny's.
He wrote: "I'd create a new group (say, foo-bin-users) and add
your user to that group."

It is also the same as my proposed solution #2 (I just used
a different group name).

Also, I can't strip the setuid bit off, otherwise foo-bin
won't run with root privileges.

> but the end result is you can avoid using a set[gu]id
> and hardcoding a check in the binary.

Right. That's what I did in my proposed solution #2.

It's not yet obvious to me (at this point) why it's a terrible idea
to hard-code the check in the binary, though.

Regards.

On 31/10/2021 22:04, Rainer Weikusat wrote:

> Noob writes:
>
>> I've written my first Linux set-user-id-root program (let's call it foo-bin)
>>
>> foo-bin is suid-root because:
>> 1) foo-bin is supposed to be run by an unprivileged user,
>> 2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)
>
> [...]
>
>> There's a different approach that would also work:
>> 1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
>> 2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
>
> That's what I usually do as a decision re: who is or isn't allowed to
> run this falls into the realm of administrative policy which shouldn't
> be hardcoded (IMHO).

You make a convincing argument.

> Also, 4710 is sufficient: It's not necessary to read a file in order to
> execute it, ie, while the kernel obviously has to, processes running
> with the uid of a user supposed to be allowed to execute a file don't
> need to read its contents.

Your answer makes me wonder:
How much/little additional security do I get from mode 4710 instead of 4750?
In other words, what bad things can user12345 do if they can read the
ELF executable file?
Maybe disassemble the code? To prepare a ROP exploit in advance?

Regards.

Noob <root@127.0.0.1> wrote:
>
> It's not yet obvious to me (at this point) why it's a terrible idea
> to hard-code the check in the binary, though.

The main issue with having the check you propose hard-coded
inside the program will only allow 1 specific user to
execute.

What happens if you want other people to run the program ?

Also there is no guarantee user '12345' does not already
exist on a different system.

You may be forced to maintain separate binaries on each
different system or maintain separate configuration file the
program reads in to determine who can run it.

To me, best to use security settings UN*X already provides
for 'free' instead of designing your own.

HTH
John

>
> Regards.

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:
....
>As far as I can tell, your suggestion is the same as Kenny's.
>He wrote: "I'd create a new group (say, foo-bin-users) and add
>your user to that group."

Right.

>It is also the same as my proposed solution #2 (I just used
>a different group name).

IIRC, your original post suggested using your user's already existing
group. This is somewhat less portable than creating a new group (speciic
to this purpose).

>Also, I can't strip the setuid bit off, otherwise foo-bin
>won't run with root privileges.

Right. I think that was just a routine "thinko" on Keith's part.

>> but the end result is you can avoid using a set[gu]id
>> and hardcoding a check in the binary.
>
>Right. That's what I did in my proposed solution #2.

Right.

>It's not yet obvious to me (at this point) why it's a terrible idea
>to hard-code the check in the binary, though.

There's nothing per se wrong with it - it will work - but it is just not
best practice - and not as "future-proof" as using a group would be.

--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:

[...]

>>It's not yet obvious to me (at this point) why it's a terrible idea
>>to hard-code the check in the binary, though.
>
> There's nothing per se wrong with it - it will work - but it is just not
> best practice - and not as "future-proof" as using a group would be.

It "will work" for as long as all systems the binary is copied to will
always associate the intended user with the hard-coded UID. As there's
nothing in the binary which screams "I have 66771 hard-coded as UID for
user grmblfzz!", that's bound to break even on a single system as stuff
like this tends to be forgotten over time.

Noob <root@127.0.0.1> writes:
> On 31/10/2021 22:04, Rainer Weikusat wrote:
>> Noob writes:

[...]

>> Also, 4710 is sufficient: It's not necessary to read a file in order to
>> execute it, ie, while the kernel obviously has to, processes running
>> with the uid of a user supposed to be allowed to execute a file don't
>> need to read its contents.
>
> Your answer makes me wonder:
> How much/little additional security do I get from mode 4710 instead of 4750?
> In other words, what bad things can user12345 do if they can read the
> ELF executable file?
> Maybe disassemble the code? To prepare a ROP exploit in advance?

Some protection against someone analysing the binary in order to find a
way to exploit it. That's presumably more than a bit theoretical, hence,
this is something of a "ticking the box" exercise. OTOH, it can be done
easily and there's usually nothing which can be gained by allowing read
access.

I usually do it because I expect to have to deal with the output of
"pen testers" (aptly named as their work consists of testing that they
can use a pen to write down a list of possibly existing vulnerabilities
blindly) who will flag all unticked boxes they find somewhere as
Unticked !!1 (OMG !!2).

In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>> In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:
>
>[...]
>
>>>It's not yet obvious to me (at this point) why it's a terrible idea
>>>to hard-code the check in the binary, though.
>>
>> There's nothing per se wrong with it - it will work - but it is just not
>> best practice - and not as "future-proof" as using a group would be.
>
>It "will work" for as long as all systems the binary is copied to will
>always associate the intended user with the hard-coded UID. As there's
>nothing in the binary which screams "I have 66771 hard-coded as UID for
>user grmblfzz!", that's bound to break even on a single system as stuff
>like this tends to be forgotten over time.

IOW, you agree with me, 100%. Thanks.

--
A racist, a Nazi, and a Klansman walk into a bar...

Bartender says, "What will it be, Mr. Trump?"

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:
>>
>>[...]
>>
>>>>It's not yet obvious to me (at this point) why it's a terrible idea
>>>>to hard-code the check in the binary, though.
>>>
>>> There's nothing per se wrong with it - it will work - but it is just not
>>> best practice - and not as "future-proof" as using a group would be.
>>
>>It "will work" for as long as all systems the binary is copied to will
>>always associate the intended user with the hard-coded UID. As there's
>>nothing in the binary which screams "I have 66771 hard-coded as UID for
>>user grmblfzz!", that's bound to break even on a single system as stuff
>>like this tends to be forgotten over time.
>
> IOW, you agree with me, 100%. Thanks.

I don't. Hard-coding system configuration information will work for as
long as the binary is regarded as configuration and the system
configuration as binary, IOW, what's supposed to be changeable by users
becomes cast in stone in this way while developers can "save some work"
in exchange for that.

I consider this a wrong design choice.