[gentoo-user] Re: How many ways are there for a user to increase their permissions?
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
[gentoo-user] Re: How many ways are there for a user to increase their permissions?
On 04/18/10 11:02, Jonathan wrote: On Sun, 18 Apr 2010 08:29:37 +1000 Lie Ryan lie.1...@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?
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] Re: How many ways are there for a user to increase their permissions?
On Fri, 16 Apr 2010 17:25:18 -0700 walt w41...@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!
[gentoo-user] Re: 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
Re: [gentoo-user] Re: How many ways are there for a user to increase their permissions?
On Sun, 18 Apr 2010 08:29:37 +1000
Lie Ryan lie.1...@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=1chap=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
[gentoo-user] Re: How many ways are there for a user to increase their permissions?
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?
On Sat, 17 Apr 2010 20:05:23 -0700 walt w41...@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.
[gentoo-user] Re: 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
