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-18-2010, 03:05 AM
walt
 
Default 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.
 
Old 04-18-2010, 04:15 AM
Jonathan
 
Default How many ways are there for a user to increase their permissions?

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

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.
 
Old 04-18-2010, 05:41 AM
Mike Edenfield
 
Default How many ways are there for a user to increase their permissions?

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
 
Old 04-18-2010, 08:23 AM
Lie Ryan
 
Default 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.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)
 
Old 04-18-2010, 05:31 PM
Alan McKinnon
 
Default 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
 
Old 04-18-2010, 05:45 PM
Alan McKinnon
 
Default How many ways are there for a user to increase their permissions?

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
 
Old 04-19-2010, 10:41 PM
Kerin Millar
 
Default 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
 

Thread Tools




All times are GMT. The time now is 01:48 PM.

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