FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 04-17-2010, 12:25 AM
walt
 
Default How many ways are there for a user to increase their permissions?

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
 
Old 04-17-2010, 06:20 PM
Mick
 
Default How many ways are there for a user to increase their permissions?

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
 
Old 04-17-2010, 08:45 PM
David W Noon
 
Default How many ways are there for a user to increase their permissions?

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)
================================================== ====================
 
Old 04-17-2010, 09:32 PM
Jonathan
 
Default 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.

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
 
Old 04-17-2010, 09:59 PM
KH
 
Default How many ways are there for a user to increase their permissions?

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
 
Old 04-17-2010, 09:59 PM
Jonathan
 
Default How many ways are there for a user to increase their permissions?

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!
 
Old 04-17-2010, 10:06 PM
Jonathan
 
Default How many ways are there for a user to increase their permissions?

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.
 
Old 04-17-2010, 10:29 PM
Lie Ryan
 
Default How many ways are there for a user to increase their permissions?

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.
 
Old 04-17-2010, 11:46 PM
David W Noon
 
Default How many ways are there for a user to increase their permissions?

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)
================================================== ====================
 
Old 04-18-2010, 01:02 AM
Jonathan
 
Default How many ways are there for a user to increase their permissions?

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
 

Thread Tools




All times are GMT. The time now is 07:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org