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");
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)
2) allow group to run foo-bin, not others (chmod 4750 foo-bin)
"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.
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.
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.
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.
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.
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.
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.
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?
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 :)
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!
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
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 ;)
On 31/10/2021 01:23, John McCue wrote:<snip>
Kenny McCormack wrote:
Noob wrote:
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.
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)
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).
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.
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.
but the end result is you can avoid using a set[gu]id
and hardcoding a check in the binary.
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.
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.
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.
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?
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.
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.
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.
In article <87h7cuo7xp.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
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.
Right. We totally agree. Note: You may have to go back and read
carefully, and note which parts were written by who and when and why. It make take some careful reading to get the point.
I don't agree with your "it will work, it's just not best practice and
not as future proof as" judgement. It will only 'work' under very specific >circumstances and at the expense of breaking other parts of the system.
That's something people might (for more or less good reasons) not be
worried about but this should at least be an informed choice.
Figuratively spoken: Kicking the door to one's home in instead of
opening it with a key will also 'work'. But afterwards, the door won't
work anymore.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
...
I don't agree with your "it will work, it's just not best practice and
not as future proof as" judgement. It will only 'work' under very specific >>circumstances and at the expense of breaking other parts of the system.
That's something people might (for more or less good reasons) not be >>worried about but this should at least be an informed choice.
Figuratively spoken: Kicking the door to one's home in instead of
opening it with a key will also 'work'. But afterwards, the door won't
work anymore.
Oh well. Back to reading comprehension school for you...
I said "It will work (*), but it is not best practice (**)". What more can
I say?
(*) Which it will.
(**) Which it (clearly) isn't.
gazelle@shell.xmission.com (Kenny McCormack) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
...
I don't agree with your "it will work, it's just not best practice and >>>not as future proof as" judgement. It will only 'work' under very specific >>>circumstances and at the expense of breaking other parts of the system.
That's something people might (for more or less good reasons) not be >>>worried about but this should at least be an informed choice.
Figuratively spoken: Kicking the door to one's home in instead of
opening it with a key will also 'work'. But afterwards, the door won't >>>work anymore.
Oh well. Back to reading comprehension school for you...
I said "It will work (*), but it is not best practice (**)". What more can >> I say?
(*) Which it will.
(**) Which it (clearly) isn't.
And I said, Mr InNeedOfReadingComprehension, "it really doesn't work"
and providing a reason for that. People may disagree with this
assessment, but that's my opinion.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:50:25 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,376 |