[gentoo-user] How many ways are there for a user to increase their permissions?

[gentoo-user] How many ways are there for a user to increase their permissions?

[Jonathan]

I'm trying to work out how many ways there are to increase the permissions of  a user.

1: su -: Needs root password and you need to be in the group "wheel".
2: sudo: You need to be in the group "wheel" or in the /etc/sudoers file, using your own user password.
    I'm not counting gksu and gksudo they are just front ends.
3: sudoedit: This is the best way to edit text files, it uses the same rules as sudo.

4: Linux "Capabilities" or "caps": Which increases permissions on a per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW to ping.
    This is much safer than running the whole program as root. http://linux.die.net/man/7/capabilities

5: Policykit: (Give this a read http://hal.freedesktop.org/docs/PolicyKit/introduction.html )
6: Polkit: Is the new name for Policykit, it's a higher version and they do not talk to each other.
    If you run a mixed architecture there is a good chance you will have both.

7: Access Control Lists: (ACL) Very easy to setup and forget because Nautilus and others do not list the ACL settings.
    A remote windows user configuring a samba share could let more people read and write to it then Nautilus shows.

8: SUID and SGID: One of the fastest ways to open up a security hole in your system.

9: Groups: Lots of groups, but not much information on what permissions you get. http://en.gentoo-wiki.com/wiki/List_of_Groups
    Udev and Fuse use group settings right?

Did I miss any way of increasing your rights? (not counting security holes)

I see that the stable net-misc/iputils (ping) does not use capabilities. Is this included in the unstable version, or is it planned for the future?
I wish there was a way to run gedit with sudoedit, is there?
I think Polkit support for gedit is planned, does anyone know the bug number?

Right now my system has all of the above but not Linux "capabilities". I'm having very hard time working out:
Which users can do what and how.
Which groups can do what and how.
Which files can do what and who can run them.
How the user's status affects what the program can do.

Is there an all-in-one program for keeping track of all this or do I have to write one?

It's very easy for users to set their home folder to other, read, write and execute. It's not just silly users doing that, but any program running with the users rights.
There was a buggy program in Ubuntu which set your home folder to other rwx, I never worked out which one was doing that.
A fast work around was to set the user's home folder to owner root and make sure that group was set to rwx.
Is that safe? 

I'm very happy Gentoo user but I find that configuring things can get very messy.

[gentoo-user] Re: How many ways are there for a user to increase their permissions?

[walt]

On 04/16/2010 03:13 PM, Jonathan wrote:

> I'm trying to work out how many ways there are to increase the permissions of  a user.
> ...
> I'm very happy Gentoo user but I find that configuring things can get very messy.>

I've been an amateur linux/*BSD user for about ten years or so, and I would love to
answer your questions -- but I don't know the answers.  Yet.

While you and I wait for a guru to enlighten us, you might learn something here:

http://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 881 bytes --]

On Friday 16 April 2010 23:13:34 Jonathan wrote:
> I'm trying to work out how many ways there are to increase the permissions
>  of  a user.
> 
> 1: su -: Needs root password and you need to be in the group "wheel".
> 2: sudo: You need to be in the group "wheel" or in the /etc/sudoers file,
>  using your own user password. I'm not counting gksu and gksudo they are
>  just front ends.
> 3: sudoedit: This is the best way to edit text files, it uses the same
>  rules as sudo.
> 
> 4: Linux "Capabilities" or "caps": Which increases permissions on a
>  per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW to
>  ping. This is much safer than running the whole program as root.
>  http://linux.die.net/man/7/capabilities

This is a first for me.  I haven't used it before and it seems it is not set 
up on my box by default.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On Sat, 17 Apr 2010 20:30:02 +0200, Mick wrote about Re: [gentoo-user]
How many ways are there for a user to increase their permissions?:

>On Friday 16 April 2010 23:13:34 Jonathan wrote:
[snip]
>> 4: Linux "Capabilities" or "caps": Which increases permissions on a
>>  per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW
>> to ping. This is much safer than running the whole program as root.
>>  http://linux.die.net/man/7/capabilities
>
>This is a first for me.  I haven't used it before and it seems it is
>not set up on my box by default.

In fact, POSIX capabilities are a mechanism to *reduce* a program's
permissions, not increase them.

With a default system, any program that needs to do, say, one
privileged operation must be run as root.  The typical example is to
open a service port (i,e, 1023 or lower) rather than an ephemeral port
in the TCP/IP stack.  Such a program receives full root privileges,
which allow it to have full access to the filesystems, modprobe new
drivers into the kernel, etc., etc., even though it only wants to
listen on a service port.

With caps, it is given the capability (CAP_NET_BIND_SERVICE) to open
service ports without regard to the userid under which it is running.
This means that it will *NOT* have permissions to modprobe drivers,
mess about with files arbitrarily, etc.

man 7 capabilities

If you don't have that man page, you will need to emerge libcap.
-- 
Regards,

Dave  [RLU #314465]
======================================================================
dwnoon@ntlworld.com (David W Noon)
======================================================================

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Jonathan]

On Sat, 17 Apr 2010 21:45:57 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> In fact, POSIX capabilities are a mechanism to *reduce* a program's
> permissions, not increase them.

It's true that Linux "capabilities" are used to replace SUID and that does reduce the programs permissions.
On the other hand programs like Wine. Which no one would never run with SUID could be run with CAP_NET_RAW.
That would be a increase in permissions. Wine needs to be able to ping because some program need to use IPX[1],
Like Red Alert 2. Someone has made a patch for Red Alert 2 to use TCP/IP and I can not think of another program off the top of my head.

That information came from "man 7 capabilities". So I guess it's all about how you look at it.

[1] http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[KH]

Am 17.04.2010 23:32, schrieb Jonathan:
> On Sat, 17 Apr 2010 21:45:57 +0100
> David W Noon<dwnoon@ntlworld.com>  wrote:
>
>> In fact, POSIX capabilities are a mechanism to *reduce* a program's
>> permissions, not increase them.
>
> It's true that Linux "capabilities" are used to replace SUID and that does reduce the programs permissions.
> On the other hand programs like Wine. Which no one would never run with SUID could be run with CAP_NET_RAW.
> That would be a increase in permissions. Wine needs to be able to ping because some program need to use IPX[1],
> Like Red Alert 2. Someone has made a patch for Red Alert 2 to use TCP/IP and I can not think of another program off the top of my head.
>
> That information came from "man 7 capabilities". So I guess it's all about how you look at it.
>
> [1] http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange
>

Sounds a little like putting someone in prison and than telling him 
walking through the prison yard is increasing his freedom.

kh

Re: [gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Jonathan]

On Fri, 16 Apr 2010 17:25:18 -0700
walt <w41ter@gmail.com> wrote:

> I've been an amateur linux/*BSD user for about ten years or so, and I would love to
> answer your questions -- but I don't know the answers.  Yet.

Around 4 years, 3 years with Ubuntu and one with Gentoo.

> While you and I wait for a guru to enlighten us, you might learn something here:
> 
> http://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook

I had a look at it. The whole thing is a rant. I think half of it does not apply to Linux and it's all very out of date.
On the other hand in "Accidents Will Happen" he talks about 'rm'.
I have never done a 'rm /' but I have done 'chmod 660 /', it made my blood run cold but that was very easy to fixes.
Now I always use the 'u+rwx' syntax.

Still waiting on the guru's! 

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Jonathan]

On Sat, 17 Apr 2010 23:59:07 +0200
KH <gentoo-user@konstantinhansen.de> wrote:

> Sounds a little like putting someone in prison and than telling him 
> walking through the prison yard is increasing his freedom.

As Linux is a prison for programs then I guess your right.

[gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Lie Ryan]

On 04/17/10 08:13, Jonathan wrote:
> I'm trying to work out how many ways there are to increase the permissions of  a user.
> 
> 1: su -: Needs root password and you need to be in the group "wheel".
> 2: sudo: You need to be in the group "wheel" or in the /etc/sudoers file, using your own user password.
>     I'm not counting gksu and gksudo they are just front ends.
> 3: sudoedit: This is the best way to edit text files, it uses the same rules as sudo.

sudoedit is mainly just a shortcut for "sudo $EDITOR" (plus doing a few
things).

> 4: Linux "Capabilities" or "caps": Which increases permissions on a
> per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW
> to ping.
>     This is much safer than running the whole program as root.
> http://linux.die.net/man/7/capabilities
> 5: Policykit: (Give this a read http://hal.freedesktop.org/docs/PolicyKit/introduction.html )
> 6: Polkit: Is the new name for Policykit, it's a higher version and they do not talk to each other.
>     If you run a mixed architecture there is a good chance you will have both.
> 8: SUID and SGID: One of the fastest ways to open up a security hole in your system.

Everything above (su,sudo,policykit,polkit) are just sugar for
permission bits (owner,group,others+SUID,GUID); attempting to give finer
control over the permissions or provide convenience services.

> 9: Groups: Lots of groups, but not much information on what
>  permissions you get. http://en.gentoo-wiki.com/wiki/List_of_Groups
>     Udev and Fuse use group settings right?

The basis of all Linux security scheme is the file permission bits
(owner,group,other) and the SUID/GUID bit (ACL is a distinct security
scheme, so we're explicitly excluding it here). Everything else is just
sugar. If you want to lock everything, just remove the SUID/GUID-bit
from all executables in your system (except for a select few) and remove
all groups (make sure you know what you're doing though, lots of program
won't work if you really do that). Starting from step zero, you can have
very fine control over everything.

> 7: Access Control Lists: (ACL) Very easy to setup and forget because
> Nautilus and others do not list the ACL settings.
>     A remote windows user configuring a samba share could let more
> people read and write to it then Nautilus shows.

ACL is largely there for compatibility with Windows' permission scheme,
it's a distinct security scheme than Linux.

> Did I miss any way of increasing your rights? (not counting security holes)

Most security holes in Linux comes from a SUID program that lets
untrusted programs into the "trusted-space".

> I see that the stable net-misc/iputils (ping) does not use capabilities.
> Is this included in the unstable version, or is it planned for the future?
> I wish there was a way to run gedit with sudoedit, is there?
> I think Polkit support for gedit is planned, does anyone know the bug number?
> 
> Right now my system has all of the above but not Linux "capabilities".
> I'm having very hard time working out:
> Which users can do what and how.
> Which groups can do what and how.
> Which files can do what and who can run them.
> How the user's status affects what the program can do.

All users can modify the permission bits for the files they owned,
everything else is governed by the permission bits.
Except for root, which has full access to everything.

If you want simplify your environment, you can clear all the `group` and
`other` permission bits from all files in your computer and everyone
(except root) will only have access to files they own. Then you can
start adding permissions on case-by-case basis. Too much hassle though,
I think.

> Is there an all-in-one program for keeping track of all this or do I have to write one?
> 
> It's very easy for users to set their home folder to other, read, write
> and execute. It's not just silly users doing that, but any program running
> with the users rights.
> There was a buggy program in Ubuntu which set your home folder to other
> rwx, I never worked out which one was doing that.

the only way the program can chmod a file in your home folder is because
the program have the permission to chmod a file in your home folder. The
only program that have permission to chmod a file in your home folder is
the one run with EUID-root or EUID-owner. The only way a program can be
run with EUID root is they are executed by root himself or a SUID-root
program. The only way a program can be run with EUID owner is SUID-owner
program or program executed by the owner himself.

However, I don't think buggy program is the case here. It is much more
likely that you accidentally runs chmod on your home folder when you
actually want to run it in another directory.

> A fast work around was to set the user's home folder to owner root and
> make sure that group was set to rwx. Is that safe?

You can use this to find all SUID program accesible by your user:
find / -perm -u+s -exec ls -l '{}' \; 2> /dev/null


I found sudo, although very handy for desktop, is a huge security hole.
And is inadequate for any secure system. This is simply because if you
run a program as sudo, then in the next five minute you start a
malicious program *without* sudo; the malicious program can gain root
access by stealing your previous sudo's timestamp (yes, it can steal the
timestamp without being explicitly invoked with sudo[1]). Before running
a potentially untrusted program, you must explicitly kill your sudo
timestamp with `sudo -k` or set sudo to not use timestamp. Better yet,
don't use sudo on secure systems.

[1] the malicious program only need to invoke sudo on themselves and
they get root access without you ever prepending the magic word to the
program.

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Sat, 17 Apr 2010 23:40:01 +0200, Jonathan wrote about Re:
[gentoo-user] How many ways are there for a user to increase  their
permissions?:

>On Sat, 17 Apr 2010 21:45:57 +0100
>David W Noon <dwnoon@ntlworld.com> wrote:
>
>> In fact, POSIX capabilities are a mechanism to *reduce* a program's
>> permissions, not increase them.
>
>It's true that Linux "capabilities" are used to replace SUID and that
>does reduce the programs permissions. On the other hand programs like
>Wine. Which no one would never run with SUID could be run with
>CAP_NET_RAW. That would be a increase in permissions. Wine needs to be
>able to ping because some program need to use IPX[1], Like Red Alert
>2. Someone has made a patch for Red Alert 2 to use TCP/IP and I can
>not think of another program off the top of my head.

If any Joe Schmoe could imbue a program with capabilities, this might
be true.  But that's not the way the system works.

Only root can run the setcap program to add capabilities to a program,
at least on a normal, UNIX-style security system.  On a role-based
security system, even root might not be permitted to do this.

>That information came from "man 7 capabilities". So I guess it's all
>about how you look at it.
>
>[1] http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange

Unfortunately, I'm old enough to have used IPX/SPX networking in the
days when Novell Netware (a.k.a. Slowvell Slugware) was considered a
serious network system.
-- 
Regards,

Dave  [RLU #314465]
======================================================================
dwnoon@ntlworld.com (David W Noon)
======================================================================

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Jonathan]

On Sun, 18 Apr 2010 08:29:37 +1000
Lie Ryan <lie.1296@gmail.com> wrote:

> sudoedit is mainly just a shortcut for "sudo $EDITOR" (plus doing a few
> things).

sudoedit is safer then sudo because sudoedit runs as root but nano (The editor) runs as your user.
sudoedit uses a fixed path which is compiled into the program (The was a thread about changing the editor on this mailing some time ago. ).

> Everything above (su,sudo,policykit,polkit) are just sugar for
> permission bits (owner,group,others+SUID,GUID); attempting to give finer
> control over the permissions or provide convenience services.

Mess up the configuration and you may as well hand out the root password.

> The basis of all Linux security scheme is the file permission bits
> (owner,group,other) and the SUID/GUID bit (ACL is a distinct security
> scheme, so we're explicitly excluding it here). Everything else is just
> sugar. If you want to lock everything, just remove the SUID/GUID-bit
> from all executables in your system (except for a select few) and remove
> all groups (make sure you know what you're doing though, lots of program
> won't work if you really do that). Starting from step zero, you can have
> very fine control over everything.

I just checked my system for files not owned by me and had a non root group set to rw.
I found "/usr/share/games/eternal-lands" with rw set and all the sub-folders and files.
It would be very easy to do a DOS attack on a system side partition but then again
the same could be said about "/tmp".

If you setup quotas for the users home folder. Ones the home folder is full the
user will look for another place to save they files.
When I was at school. A kid ran out of space so he started to move his files to the recycling bin, before creating
his new files. Of course the recycling bin had no quota nor was it backed up.
Some time after that the admin set a quota on the recycling bin and the kid asked why he could not save.
So I showed him how to empty his recycling bin. I was 10 second away from deleting all his work
before he pointed out he keeps his work in there!
That was some fun on windows but it could happen with Linux "/tmp" is wiped after each reboot and any
other places that is not backed up, does not have quota and the user can write to.

> Most security holes in Linux comes from a SUID program that lets
> untrusted programs into the "trusted-space".

53 SUID or GUID programs on my system!
Why does cdrecord have SUID set?
"/dev/sr0" is in the cdrom group with rw set so
SUID should not be needed in the first place.

> If you want simplify your environment, you can clear all the `group` and
> `other` permission bits from all files in your computer and everyone
> (except root) will only have access to files they own. Then you can
> start adding permissions on case-by-case basis. Too much hassle though,
> I think.

I could remove other from all the SUID programs then setup a ACL group that could run then.
That would stop RandomFool from running then in the first place.
I could see that being useful for say "mount" (Yes it's has SUID set). If the was security hole in it.

> the only way the program can chmod a file in your home folder is because
> the program have the permission to chmod a file in your home folder. The
> only program that have permission to chmod a file in your home folder is
> the one run with EUID-root or EUID-owner. The only way a program can be
> run with EUID root is they are executed by root himself or a SUID-root
> program. The only way a program can be run with EUID owner is SUID-owner
> program or program executed by the owner himself.

What does the E in EUID stand for?
I did a quick Google and found RUID and EUID but I did not find anything else.

> However, I don't think buggy program is the case here. It is much more
> likely that you accidentally runs chmod on your home folder when you
> actually want to run it in another directory.

No, this was before I used chmod for anything (read noob) I set the permissions back with nautilus
but after each login or was reboot and login. The permissions got set back to o+rwx.
The was a very help error box at login that said "The permissions for your home folder are set wrong.".
That was the helpful version the real version was talking about some file in "~/.config".

> You can use this to find all SUID program accesible by your user:
> find / -perm -u+s -exec ls -l '{}' \; 2> /dev/null

Yes, I have being making use of this page http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=6
for a long time.

> I found sudo, although very handy for desktop, is a huge security hole.
> And is inadequate for any secure system. This is simply because if you
> run a program as sudo, then in the next five minute you start a
> malicious program *without* sudo; the malicious program can gain root
> access by stealing your previous sudo's timestamp (yes, it can steal the
> timestamp without being explicitly invoked with sudo[1]). Before running
> a potentially untrusted program, you must explicitly kill your sudo
> timestamp with `sudo -k` or set sudo to not use timestamp. Better yet,
> don't use sudo on secure systems.

Wow... I never thought about that. I run sudo on my system 4 to 6 times a day if not more.
Can tell me the setting please. I had a quick look at man pages and Gentoo docs but I did not see it.
Gentoo sudo guide [1] could use a update about this. it was right under my nose but I missed it...

If some leaves they PC for 5 mins you could run
"nano ~/.bashrc" and add "export PATH=/home/user/.bin:$PATH"
then make a file called "sudo" write something to nick the password and by it on to sudo and then clean up after it
self.
Just for fun I did that to one of my terminal tabs, with the script running "echo HAHA!".
With in 20 minutes I had run sudo two times. 


[1] http://www.gentoo.org/doc/en/sudo-guide.xml

[gentoo-user] Re: How many ways are there for a user to increase their permissions?

[walt]

On 04/17/2010 06:02 PM, Jonathan wrote:

> What does the E in EUID stand for?
> I did a quick Google and found RUID and EUID but I did not find anything else.

Did you really type what you meant?  Doesn't make much sense as is, so I assume
there is a typo in there somewhere.

Have a leisurely browse through /usr/include/unistd.h to answer your question.

Re: [gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Jonathan]

On Sat, 17 Apr 2010 20:05:23 -0700
walt <w41ter@gmail.com> wrote:

> Have a leisurely browse through /usr/include/unistd.h to answer your question.
That file has answer to my question.
Thank you.

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Jonathan]

On Sun, 18 Apr 2010 00:46:25 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> If any Joe Schmoe could imbue a program with capabilities, this might
> be true.  But that's not the way the system works.

Sorry, I think i'm missing your point.

> Only root can run the setcap program to add capabilities to a program,
> at least on a normal, UNIX-style security system.  On a role-based
> security system, even root might not be permitted to do this.

If I had the root password to own system(which I do...) and I wanted Wine to uses IPX
without running as root. I would set "setcap cap_net_raw=ep /usr/bin/wine" as root.
Then I could run Wine as my normal user.

No one in there right mind would run Wine as root. If you did you may as well use Windows.

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Mike Edenfield]

On 4/18/2010 12:29 AM, Jonathan wrote:
> On Sun, 18 Apr 2010 00:46:25 +0100
> David W Noon<dwnoon@ntlworld.com>  wrote:
>
>> If any Joe Schmoe could imbue a program with capabilities, this might
>> be true.  But that's not the way the system works.
>
> Sorry, I think i'm missing your point.
>
>> Only root can run the setcap program to add capabilities to a program,
>> at least on a normal, UNIX-style security system.  On a role-based
>> security system, even root might not be permitted to do this.
>
> If I had the root password to own system(which I do...) and I wanted Wine to uses IPX
> without running as root. I would set "setcap cap_net_raw=ep /usr/bin/wine" as root.
> Then I could run Wine as my normal user.
>
> No one in there right mind would run Wine as root. If you did you may as well use Windows.

You say "no one in their right mind" would run Wine as root. 
  But if you did not have capabilities support available, 
and wanted Wine to use IPX, then you wouldn't have any other 
choice but to run Wine as root.

By using capabilities, you aren't increasing Wines 
permissions, you are decreasing the permissions needed to 
support IPX.  Trying to compare Wine without IPX to Wine 
with CAP_NET_RAW isn't a fair comparison, as the two don't 
have the same feature set and thus clearly don't have the 
same security needs.

--Mike

[gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Lie Ryan]

On 04/18/10 11:02, Jonathan wrote:
> On Sun, 18 Apr 2010 08:29:37 +1000
> Lie Ryan <lie.1296@gmail.com> wrote:
>
>> sudoedit is mainly just a shortcut for "sudo $EDITOR" (plus doing a
>> few things).
>
> sudoedit is safer then sudo because sudoedit runs as root but nano
> (The editor) runs as your user.
> sudoedit uses a fixed path which is compiled into the program

Yes, that's the "few things" part, sudoedit does solves a couple of
security issues that you'd have if you start editor manually, probably
calling it "just a shortcut" is too much undermining.

>> Everything above (su,sudo,policykit,polkit) are just sugar for
>> permission bits (owner,group,others+SUID,GUID); attempting to give
>> finer control over the permissions or provide convenience services.
>
> Mess up the configuration and you may as well hand out the root
> password.

They're much better than manual management though, which is unless
you're forty-two security wizard in one body you will get it wrong.

>> Most security holes in Linux comes from a SUID program that lets
>> untrusted programs into the "trusted-space".
>
> 53 SUID or GUID programs on my system!
> Why does cdrecord have SUID set?

No idea.

>> I found sudo, although very handy for desktop, is a huge security
>> hole. And is inadequate for any secure system. This is simply
>> because if you run a program as sudo, then in the next five minute
>> you start a malicious program *without* sudo; the malicious program
>> can gain root access by stealing your previous sudo's timestamp
>> (yes, it can steal the timestamp without being explicitly invoked
>> with sudo[1]). Before running a potentially untrusted program, you
>> must explicitly kill your sudo timestamp with `sudo -k` or set sudo
>> to not use timestamp. Better yet, don't use sudo on secure systems.
>
> Wow... I never thought about that. I run sudo on my system 4 to 6
>> times a day if not more. Can tell me the setting please.

Setting for the timeout? See `man sudoers` and look at
timestamp_timeout. Setting for allowing program to steal timestamp?
Don't worry, it's already default.

> I had a quick look at man pages and Gentoo docs but I did not see it.
> Gentoo sudo guide [1] could use a update about this. it was right
> under my nose but I missed it...
>
> If some leaves they PC for 5 mins you could run
> "nano ~/.bashrc" and add "export PATH=/home/user/.bin:$PATH"
> then make a file called "sudo" write something to nick the password
> and by it on to sudo and then clean up after it self.

I believe the developers of `sudo` considered security against malicious
people with physical access to the computer is out of their scope.
Problem is, that means malicious people only need to trick a sudoers
into running a piece of complex code and say "you're not running my
script with sudo, so the script can't do no harm to system".

When I first used sudo, I thought by invoking sudo for trusted program
only and omitting sudo for everything else and thought the system would
be secure. That's a false sense of security. As long as you're a
root-sudoers, all program you run can gain root access any time they
need to. They just need to daemonize and poll every few minutes for an
updated timestamp.

> Just for fun I did that to one of my terminal tabs, with the script
> running "echo HAHA!".

I once written a script that have this in the first line:

if [ $UID != 0 ]; then
   sudo $0
   quit
fi
# do business that requires root

the script runs without asking password if I still have active timestamp
from running another program. How convenient! (and makes me shivers)

Re: [gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Alan McKinnon]

On Sunday 18 April 2010 05:05:23 walt wrote:
> On 04/17/2010 06:02 PM, Jonathan wrote:
> > What does the E in EUID stand for?
> > I did a quick Google and found RUID and EUID but I did not find anything
> > else.
> 
> Did you really type what you meant?  Doesn't make much sense as is, so I
> assume there is a typo in there somewhere.
> 
> Have a leisurely browse through /usr/include/unistd.h to answer your
> question.

Nice retort :-)

But to answer his question

The "E" stands for "effective". His apps are running as a normal user with his 
UID. In kernel-speak they are effectively running with that UID, hence the 
term EUID.

When you run an app with sudo (or any other app that raises priviledges), sudo 
is SUID so it runs as root, who permits the user's app to run as root. The UID 
of that running app is 0, but it's launched by a regular user.

That's why we have EUID. It's not the same thing as UID.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] How many ways are there for a user to increase their permissions?

[Alan McKinnon]

On Sunday 18 April 2010 07:41:51 Mike Edenfield wrote:
> On 4/18/2010 12:29 AM, Jonathan wrote:
> > On Sun, 18 Apr 2010 00:46:25 +0100
> > 
> > David W Noon<dwnoon@ntlworld.com>  wrote:
> >> If any Joe Schmoe could imbue a program with capabilities, this might
> >> be true.  But that's not the way the system works.
> > 
> > Sorry, I think i'm missing your point.
> > 
> >> Only root can run the setcap program to add capabilities to a program,
> >> at least on a normal, UNIX-style security system.  On a role-based
> >> security system, even root might not be permitted to do this.
> > 
> > If I had the root password to own system(which I do...) and I wanted Wine
> > to uses IPX without running as root. I would set "setcap cap_net_raw=ep
> > /usr/bin/wine" as root. Then I could run Wine as my normal user.
> > 
> > No one in there right mind would run Wine as root. If you did you may as
> > well use Windows.
> 
> You say "no one in their right mind" would run Wine as root.
>   But if you did not have capabilities support available,
> and wanted Wine to use IPX, then you wouldn't have any other
> choice but to run Wine as root.
> 
> By using capabilities, you aren't increasing Wines
> permissions, you are decreasing the permissions needed to
> support IPX.  Trying to compare Wine without IPX to Wine
> with CAP_NET_RAW isn't a fair comparison, as the two don't
> have the same feature set and thus clearly don't have the
> same security needs.

Or explain it like this:

The kernel can do anything the software and hardware supports.

Normally, the Unix kernel gives those same rights to any app running with UID 
0 (NOT the same thing as the root account - that's just a label. To prove it, 
create a new account "toor" with UID 0 and log in as it).

Unix permissions are traditionally an all or nothing approach. You can do what 
root can do, or you can do what users can do. This got modified with the 
introduction of groups and group owners a long time ago, where a user could 
get the rights of the group owner of an app/file is they were members of the 
group.

Please note that it's the kernel doing this, not the root account. The kernel 
trusts the root account and does what it says. But traditional Unix 
permissions have the problem of not being fine-grained enough. For the most 
part this works fine, but in the odd case where you need more, you are up a 
creek without a paddle and have to give everything to get a little. That's why 
we have SUID and it's bastard progeny GUID. A more ridiculous solution is very 
hard to find.

So this whole argument about "do caps raise or lower permissions?" is utterly 
pointless and leads nowhere. It's not even the point, as there are two 
viewpoints and one seems to go up and one seems to go down.

caps do this:

Allow fine-grained access control to resources, without having to give 
everything to get something.

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: How many ways are there for a user to increase their permissions?

[Kerin Millar]

On 18/04/2010 02:02, Jonathan wrote:

[snip]

> 53 SUID or GUID programs on my system!
> Why does cdrecord have SUID set?
> "/dev/sr0" is in the cdrom group with rw set so
> SUID should not be needed in the first place.

Device node permissions are not the concern. If I recall correctly, it 
is so that it may (a) call mlockall() (b) employ the SCHED_RR (realtime) 
scheduling policy.

Cheers,

--Kerin