Lack of informations about the flaw of the use of sudo
Edgard Schmidt
schmidt at edik.ch
Fri Sep 8 00:59:06 UTC 2017
Hi,
about one year ago I mailed [1] to this list having concerns about the
documentation of the Ubuntu user concept. You answered extensively and
advised me to contact the security team, and so I did. Although the
security team's responses were very detailed, they could not answer
all my questions due to a lack of time. But they allowed me to forward
their mails so that the discussion can be continued here, or at least
their messages can be archived. Unfortunately I did not manage to
write this mail any sooner. Please accept my apologies for this
extreme delay. Having a stressful time and procrastination are not a
good combination.. However, I thank you for your replies, and I would
be glad if you were still willing to discuss this topic.
To sum up my first mail, I think that too many people misunderstand
the purpose of sudo in Ubuntu, and the documentation supports these
misunderstandings instead of resolving them. The point is that users
who are in the group "sudo" are basically on the same security level
as the root user. The security team confirmed this, but parts of the
documentation are still implying that the usage of sudo gives the
users some kind of efficient protection.
I start answering your replies, before I draw my conclusions from the
conversation with the security team. At the end you can read the the
forwarded emails. I tried to write this mail in a way that you do not
necessarily have to read the forwarded mails. However, those mails are
a bit more detailed on some points.
@Conno Boel (
https://lists.ubuntu.com/archives/ubuntu-doc/2016-September/020171.html
):
> That being said, bash is a tool that comes with most distributions, so
> maybe a little more googling might turn up an upstream reporting tool
> for linux. (For me it didn't, but I didn't put in too much effort).
I guess the only way of preventing such an attack on upstream level is
removing features like bashrc which is surely not an option. Removing
write permission to .bashrc would also prevent this attack but should
not be an general solution for Ubuntu users either because there are
many other similar attack vectors. Consequently, you should have to
remove write permissions from many more files in the user's home
directory such as .vimrc, .xinitrc and so on. This would lead to a
great impact on the usability.
> From all angles though, you'd also need file creation and the ability to
> chmod the phising sudo file too, at which point I'd argue that the
> target system is already breached anyways.
>
> Which, in my limitted knowledge would make this a privilege escalation
> vulnerability. Not to say it's not bad, but it's atleast not something
> to directly panic about :)
Maybe there is no need for panic. But such scenarios are still
possible. Moreover, since the documentation already warns against
logins as root for daily use, it should point out too that using a
sudo account for daily use is _not_ necessarily more secure.
@Alberto Salvia Novella (
https://lists.ubuntu.com/archives/ubuntu-doc/2016-September/020172.html
):
> The problem is that in practise this is highly improbable. Modern
> browsers design is compartmentalized, which means no function access
> directly the file system but does using a common interface.
Even modern browsers and sand boxes can be vulnerable [2]. However,
the sudo privilege escalation scenario is not limited to exploitations
of vulnerable browsers. Potentially every user application can contain
vulnerabilities which allow such code executions, I guess. Even if
such exploitations were so improbable, a correction of the relevant
documentation parts would just be consequent because other parts of
the wiki actually describe protections against these exploitations [3].
@Gunnar Hjalmarsson (
https://lists.ubuntu.com/archives/ubuntu-doc/2016-September/020173.html
):
> The use of sudo in Debian/Ubuntu is a replacement for logging in as
> root, and doing so wouldn't exactly be more secure, would it? With that
> said, nobody claims that the use of sudo eliminates all kinds of risks
> for hostile attacks on the parts of the system which only root can
> access. If the documentation - contrary to expectation - makes such a
> claim somewhere, it should be changed.
Well, it appears to me that the Ubuntu use of sudo eliminates only
very few risks. I point out the incorrect claims of the wiki in this
email below.
>> 1. The official documentation and the help wiki should point out
>> this issue very plainly.
>
> Don't think so. If this would be considered a threat worth mentioning,
> we should not spread the word via the docs. Security issues are
> generally kept as private as possible until they have been fixed.
Allowing daily-use sudo accounts is a design decision which I
completely understand. It's something the Ubuntu team does not want to
change. That's why I think we could and should describe the upsides
and downsides of the consequences transparently in the docs. Since the
security team allowed me to forward their messages, there is no
problem with publicity, I guess.
My summary of the discussion with the security team:
* Users who are in the sudo group have some extra permissions by
default. These permissions may be used for privilege escalations too.
* X11 provides opportunities for privilege escalations? I am not sure
if I have understood this point completely.
* In Marc Deslauriers's opinion there is no need for root protection
on single-user systems:
> On single-user systems, all your data is in your user account. There is
> absolutely nothing more that can be gained from obtaining root privileges.
I disagree with that: root protection can prevent an attacker from
installing rootkits or accessing the hardware directly. So depending
on the own security requirements, it might be worthwhile to protect
root.
* On multi-user systems it is better not to use sudo account for daily use
* There are alternatives to a basic change of the Ubuntu sudo concept
which _may_ help preventing such privilege escalation attacks
_sometimes_: AppArmor, two-factor authorization for sudo; but after
thinking it through, I cannot understand how 2FA may be a protection,
even with Seth Arnold's further instructions:
> 2FA can help -- libpam-duo, libpam-google-authenticator, etc., may
> provide the ability to block malicious uses of sudo directly by
> programs. This would probably also require sudo configuration changes to
> force authentication every single time sudo is used, and not allow
> per-tty tickets.
* The following question was not directly answered by the sec team: by
comparison between root and a sudo user, could vulnerabilities exist
which are more harmful when the attacked user is root despite the fact
that sudo is not a general protection against privilege escalations?
If I had to answer the last question, I would say such vulnerabilities
can actually exist. For example, let's say you have a vulnerability of
a software you can run both as a sudo user and as root. Let's say the
only possible exploitation of this vulnerability is the removal of
files the attacked user has write permission for. If the vulnerable
software is started by a sudo user (without sudo), the attacker should
usually not be able to gain root privileges because he can only remove
some user files. Thus, the attacker cannot remove files which are only
writable by root. On the other side, if the software is started with
root privileges, the attacker is able to remove any file. So you can
say, running this software as a sudo user is more secure than running
it as root because an exploitation is less harmful without root
privileges. Although such a vulnerability should be theoretically
possible, it seems like an edge case to me. That's why I am not sure
if you can say a sudo user and root are generally on different
security levels due to the theoretical existence of such
vulnerabilities.
In addition, I proposed the documentation of an alternative user
concept for people who want to protect root more efficiently:
> 2 user setup, root login is disabled
> * one daily-use user which is *not* a member of the sudo group -
> Let's call it Daisy
> * one sudo-user which is *only* used for root tasks - Let's call it Susy
>
> To prevent sudo from being hijacked, advanced authentication methods
> should be used. I know two solutions. Whenever the user wants to do
> root-tasks:
> * he reboots and logs in directly as Susy.
> * he makes use of a secure attention key [4] before logging in as Susy.
>
> Once logged in as Susy, he can do his root tasks with sudo as usual.
> This way, Susy will be safe even if Daisy has been compromised. By
> the way, I think this is what many people think sudo does.
The sec team did not like my idea because it is so disruptive. But I
guess, this is currently the only secure way to switch switch between
users. It appears to me, a compromised user could start a pishing
software which looks mostly like a login manager such as GDM.
Unfortunately, I have not inquired the sec team about the possibility
of such an attack. But there are open tickets for implementing smooth
AND secure login transitions with login managers [5][6]. So I think I
have a point here. However, this Daisy-Susy setup might require
further configuration effort like starting X with the current user
instead of root. It is rather an idea than a completed setup at the
moment. Besides that, this alternative concept applies rather to
desktop systems than to servers. Furthermore Seth Arnold wrote
something about it I have not understood yet:
> Even your example of Daisy and Susy only works if those logins are made
> directly to the computer -- if they're ssh connections from a single
> desktop session, that session becomes a new target.
Here is the list of the misleading wiki parts and the changes I
propose. You can also find most of this stuff in the forwarded mails,
but I have extended a few parts while trying to clarify some aspects.
* https://wiki.ubuntu.com/BasicSecurity#Don.27t_Log_in_as_Root
The explanation of this rule is implying that code which is executed
by a drive-by download cannot gain root privileges if the attacked
user is only a sudo user. But as already described, the malicious code
has plenty ways to escalate it's privileges. So it makes no difference
if the browser is started by root or by a sudo account. I would rather
call this a counterexample to that rule. It would be better to point
out that _some_ vulnerabilities may be less harmful when the attacked
user is a sudo user while (many?) other vulnerabilities are _not_
affected by the limitations of a sudo user.
* https://wiki.ubuntu.com/BasicSecurity#Least_Privileges.2C_Always
I don't know the definition of 'non-privileged user' here. If sudo
members are non-privileged users, this explanation is misleading as
well. If they are defined as privileged users, I read this part as a
hidden hint for a Daisy-Susy setup. As described before, I do not
think you should propose the separation into a regular account and a
sudo account without noting that the current login managers are
violating this security concept. In fact, I see no way other than
documenting or linking something like the Daisy-Susy setup here.
* https://help.ubuntu.com/community/RootSudo#Remove_Password_Prompt_For_sudo
People who read the text in the yellow box may assume that the
password prompt is an effective protection against malicious privilege
escalations. I would say it's at most a small protection if indeed. We
should at least note here that a well-prepared attacker could easily
bypass this password protection.
* https://help.ubuntu.com/community/RootSudo#Misconceptions
> The basic security model is the same, and therefore these two systems share
> their primary weaknesses. Any user who uses su or sudo must be considered to
> be a privileged user. If that user's account is compromised by an attacker,
> the attacker can also gain root privileges the next time the user does so.
> The user account is the weak link in this chain, and so must be protected
> with the same care as root.
This is true, but not enough:
Since the page "RootSudo" is linked by the security policy page [7],
it should describe the user account concept of Ubuntu and not only
sudo in itself. Thus, _all_ the security-related pros and cons of the
Ubuntu permission concept should be described/linked here in my
opinion. Moreover some clarifications and restructurings could be
useful. I see the following to-do list:
* List and describe the other attack vectors: X11, sudo extra permissions [8]
* Explain the pros and cons of an advanced protection of root on
single user setups ( hardware access, rootkits vs. all data in home
directory )
* Indicate whether the exploitability of some vulnerabilities is
increased if the vulnerable software has root privileges -- see the
file removal vulnerability example I mentioned above
* All this security analysis should be moved to a more visible place.
What about putting it around the sections "Background informations"
[9] or "Advantages and Disadvantages" [10]? Alternatively, we could
put an anchor link there. I am just afraid many readers don't take
note of the section "Misconceptions".
* Extend the list of optional security improvements on the security
FAQ [3] by Seth's sudo authentication enhancements and my Daisy-Susy
approach. Point out the efficiency of each improvement separately.
Link/move that list on/to the RootSudo page.
* Insert more links between the various wiki pages. It was not really
easy for me to find all relevant pages.
Some of these points require more investigation. I would be willing to
write drafts, maybe bit for bit (for time reasons). But at first, I
would like to know what you think about all that.
I did not always explain in this mail why I haven't understood some
arguments. I think the mail is long enough. If you're interested, I
explain these points of course. Anyway, thanks for reading :)
1. https://lists.ubuntu.com/archives/ubuntu-doc/2016-September/020170.html
2. I've just picked one example:
https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5455
3. https://wiki.ubuntu.com/SecurityTeam/FAQ#Sudo
4. https://www.kernel.org/doc/Documentation/SAK.txt
5. https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/237721
6. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1037653
7. https://wiki.ubuntu.com/SecurityTeam/Policies#Sudo_by_Default
8. maybe outdated (2010): https://wiki.ubuntu.com/Security/Privileges
9. https://help.ubuntu.com/community/RootSudo#Background_Information
10. https://help.ubuntu.com/community/RootSudo#Advantages_and_Disadvantages
----- Forwarded message from Edgard Schmidt -----
Date: Mon, 26 Sep 2016 03:58:36 +0200
From: Edgard Schmidt
Subject: Security of sudo-setups
To: security at ubuntu.com
Hi,
many people see a particular security-related feature in sudo that
does not exist in my opinion. So I started a little discussion on the
ubuntu-doc mailing list about the security of the Ubuntu use of sudo
[1]. I proposed some changes in the official documentation or the
wiki. However, it would seem seem that we need some professional
advice now. That's why I would appreciate it, if you answered to two
questions.
(1) Compared with running the desktop system and every software as
root, are there any security-related benefits of using sudo on desktop
systems other than those which are listed on the wiki page "RootSudo"
[2]? The wiki page purports that a normal default-configured sudo-user
are on a security level with the root user [3]. Is this correct?
I know that an attacker can hijack sudo invocations for example by
editing the ".bashrc" file if he is able to execute arbitrary code.
But I could not find out whether it is more difficult to reach this
state of code execution at non-root users than at root users. If so,
sudo-users are not at the same security level and this fact should be
documented on the wiki.
In this regard, could exist any *other* vulnerabilities which are less
dangerous when being exploited on non-root users? Please note that
this question is also confined to the comparison of running the
desktop system as root with running it as a sudo-user. That is, I do
not ask for vulnerabilities which could be exploited when the user is
doing "normal" root-tasks. Because such exploits are anyway possible
on both user setups since sudo-users do such jobs with sudo. I am
asking for vulnerabilities that affect tasks which are usually done
*without* root privileges on sudo-setups, for example browsing the web
or using a messenger. Is it really more secure doing these jobs as a
sudo-user?
No matter what the answers are, they should be present on the
documentation / wiki, together with their explanations. Based on this
informations, the users could make better decisions on their
security-related system configuration. This introduces my second
question.
(2) Let's say a user has higher security requirements and is not
satisfied by the default sudo configuration. Is it reasonable to
recommend the following configuration to him?
2 user setup, root login is disabled
* one daily-use user which is *not* a member of the sudo group - Let's
call it Daisy
* one sudo-user which is *only* used for root tasks - Let's call it Susy
To prevent sudo from being hijacked, advanced authentication methods
should be used. I know two solutions. Whenever the user wants to do
root-tasks:
* he reboots and logs in directly as Susy.
* he makes use of a secure attention key before logging in as Susy.
Once logged in as Susy, he can do his root tasks with sudo as usual.
This way, Susy will be safe even if Daisy has been compromised. By the
way, I think this is what many people think sudo does.
Please note that my mail is mainly relevant to "normal" Ubuntu desktop
systems. I am not an expert but server systems provide much more room
for useful sudo configurations, I guess.
Thank you for reading
1. https://lists.ubuntu.com/archives/ubuntu-doc/2016-September/020170.html
2. https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo
3. https://help.ubuntu.com/community/RootSudo#Misconceptions
----- End forwarded message -----
----- Forwarded message from Seth Arnold -----
Date: Mon, 26 Sep 2016 15:55:19 -0700
From: Seth Arnold
Subject: Re: Security of sudo-setups
To: Edgard Schmidt
Cc: security at ubuntu.com
Hello Edgard, thanks for writing.
You're correct that user accounts that can use sudo are basically
root-equivalent accounts. A compromised web browser, text editor, video
player, whatever a user may run, has countless routes to wait until a
user types the password, and then they're essentially free to abuse sudo
for full root privileges.
There's no good solution:
- Rebooting is entirely too much hassle just to get a secure login prompt.
- The Linux kernel's SAK key was not designed with security in mind, but
probably would suffice for those who want more security than normal.
This is almost as disruptive as a reboot, so no one uses it.
- X11 provides ample opportunities for malicious code to be malicious. It
probably doesn't belong in high-security environments.
- Even your example of Daisy and Susy only works if those logins are made
directly to the computer -- if they're ssh connections from a single
desktop session, that session becomes a new target.
When machines are locked in a data center, no one logs in directly
anyway.
There are mitigations available:
- 2FA can help -- libpam-duo, libpam-google-authenticator, etc., may
provide the ability to block malicious uses of sudo directly by
programs. This would probably also require sudo configuration changes to
force authentication every single time sudo is used, and not allow
per-tty tickets.
- AppArmor profiles can confine especially untrustworthy programs. X11
programs can still influence the operating system beyond their AppArmor
confinement, but it's more work than without AppArmor.
If you feel you can summarize these risks well for the wiki pages, please
do add these concerns. It's not simple and it's not obvious. Linking to
Solar Designer's email is probably a good idea -- there are minor quibble
points with it now, a dozen years later, but he's still basically right.
People are only willing to accept so much discomfort for security. A
good solution to the sudo issues would probably be more discomfort than
the majority would tolerate. (I, for example, don't use a separate account
solely for sudo despite knowing the advantages of such a design. I'm
content with AppAmor profiles on my network-facing applications and
exercising discipline with the programs I use.)
Thanks
----- End forwarded message -----
----- Forwarded message from Marc Deslauriers -----
Date: Tue, 27 Sep 2016 07:54:55 -0400
From: Marc Deslauriers
Subject: Re: Security of sudo-setups
To: Edgard Schmidt, security at ubuntu.com
Hi Edgar,
On 2016-09-25 09:58 PM, Edgard Schmidt wrote:
> Hi,
> many people see a particular security-related feature in sudo that does not
> exist in my opinion. So I started a little discussion on the
> ubuntu-doc mailing
> list about the security of the Ubuntu use of sudo [1]. I proposed
> some changes
> in the official documentation or the wiki. However, it would seem
> seem that we
> need some professional advice now. That's why I would appreciate it, if you
> answered to two questions.
The issue you being up in the ubuntu-doc mailing list is already mentioned in
the RootSudo wiki page:
"Any user who uses su or sudo must be considered to be a privileged user. If
that user's account is compromised by an attacker, the attacker can also gain
root privileges the next time the user does so. The user account is the weak
link in this chain, and so must be protected with the same care as root. "
If malware is running, it's already too late. On single-user systems, malware
will have access to all your files and data.
Please keep in mind that the sudo tool is only one of the attack
vectors malware
can use to escalate privileges in the default user's environment. The group
called "sudo" is also used for granting a whole slew of extra permissions,
either through policykit, or directly. For example, malware can escalate
privileges without using sudo simply by replacing the boot sector, something
that is allowed by default by the policykit privileges. If you install
libvirt,
members of the sudo group are automatically placed in the libvirtd
group, which
allows malware to trivially escalate privileges to root.
>
>
> (1) Compared with running the desktop system and every software as root, are
> there any security-related benefits of using sudo on desktop systems
> other than
> those which are listed on the wiki page "RootSudo" [2]? The wiki
> page purports
> that a normal default-configured sudo-user are on a security level
> with the root
> user [3]. Is this correct?
I don't know of any others off-hand, by if you do think of any, please
add them
to the wiki.
Yes, I agree that a normal default-configured sudo-user is a
privileged account
on the same security level as the root user.
>
> I know that an attacker can hijack sudo invocations for example by
> editing the
> ".bashrc" file if he is able to execute arbitrary code. But I could
> not find out
> whether it is more difficult to reach this state of code execution
> at non-root
> users than at root users. If so, sudo-users are not at the same
> security level
> and this fact should be documented on the wiki.
I think you're misunderstanding what the page says. Admin users who are in the
sudo group must be considered root users, and are vulnerable to all the same
attacks root users are. In other words, running with an Admin account and
getting malware is like running with root and getting malware.
>
> In this regard, could exist any *other* vulnerabilities which are
> less dangerous
> when being exploited on non-root users? Please note that this
> question is also
> confined to the comparison of running the desktop system as root
> with running it
> as a sudo-user. That is, I do not ask for vulnerabilities which could be
> exploited when the user is doing "normal" root-tasks. Because such
> exploits are
> anyway possible on both user setups since sudo-users do such jobs
> with sudo. I
> am asking for vulnerabilities that affect tasks which are usually
> done *without*
> root privileges on sudo-setups, for example browsing the web or using a
> messenger. Is it really more secure doing these jobs as a sudo-user?
On multiuser systems, it's _less_ secure doing jobs as the Admin user compared
to a regular user. On single user systems, malware has absolutely nothing more
to gain from obtaining root permissions, so it's basically equivalent in terms
of risk and exposure.
>
> No matter what the answers are, they should be present on the documentation /
> wiki, together with their explanations. Based on this informations, the users
> could make better decisions on their security-related system
> configuration. This
> introduces my second question.
I think this is described pretty well on the wiki page already. Which part do
you feel needs clarifying?
>
>
> (2) Let's say a user has higher security requirements and is not satisfied by
> the default sudo configuration. Is it reasonable to recommend the following
> configuration to him?
>
> 2 user setup, root login is disabled
> * one daily-use user which is *not* a member of the sudo group -
> Let's call it
> Daisy
> * one sudo-user which is *only* used for root tasks - Let's call it Susy
>
> To prevent sudo from being hijacked, advanced authentication methods
> should be
> used. I know two solutions. Whenever the user wants to do root-tasks:
> * he reboots and logs in directly as Susy.
> * he makes use of a secure attention key before logging in as Susy.
>
> Once logged in as Susy, he can do his root tasks with sudo as usual.
> This way,
> Susy will be safe even if Daisy has been compromised. By the way, I
> think this
> is what many people think sudo does.
If this is the amount of security you require, then by all means use
it. I think
this is so complex a scenario however that I don't feel it should be suggested
on the standard wiki page. Feel free to blog about it though!
> Please note that my mail is mainly relevant to "normal" Ubuntu
> desktop systems.
> I am not an expert but server systems provide much more room for useful sudo
> configurations, I guess.
>
It's actually quite the opposite.
On single-user systems, all your data is in your user account. There is
absolutely nothing more that can be gained from obtaining root privileges.
Therefore on normal desktop systems, having the default user be an Admin with
sudo privileges and with lax policykit permissions makes perfect sense.
On multiuser systems, there is value in attempting to become root: to
be able to
switch among users and obtain data from all users. This is why
multiuser systems
should use regular user accounts.
I hope that helps to clarify the issue for you, please don't hesitate
to ask any
more questions.
Thanks,
Marc.
----- End forwarded message -----
----- Forwarded message from Edgard Schmidt -----
Date: Thu, 06 Oct 2016 04:17:07 +0200
From: Edgard Schmidt
Subject: Re: Security of sudo-setups
To: security at ubuntu.com
Thank you for your extensive replies.
At first, I disagree with your statements which relate to server
systems. Nevertheless, could we confine ourselves on the discussion
about desktop systems maybe? Since server systems are much less
pre-configured after installation, a correct documentation of the
desktop security configuration is more important in my opinion.
Quoting Marc Deslauriers:
> I think you're misunderstanding what the page says. Admin users who are in
> the sudo group must be considered root users, and are vulnerable to all the
> same attacks root users are. In other words, running with an Admin account
> and getting malware is like running with root and getting malware.
Although the last sentence is correct, it makes me assuming that you
misunderstood my question :). Here I did not ask for the general
possibility of malicious privilege escalations. Instead, I wondered
whether being logged in as a sudo-user could limit sometimes the
possible harm of an attack _despite_ the lack of effective protections
against privilege escalations.
In regard to your answer: could getting malware be more difficult
sometimes when the attacked application is run by a non-root account?
For example, could exist buffer overflow vulnerabilities which only
allow an attacker to execute arbitrary code if the affected software
is run by root, while exploiting the same vulnerability at
non-root-users can only cause a crash? If the existence of such
vulnerabilities is possible, a sudo-user is _not_ on the same security
level with root in general even if the sudo group membership provides
privilege escalation opportunities other than sudo hijacks.
> On single-user systems, all your data is in your user account. There is
> absolutely nothing more that can be gained from obtaining root privileges.
> Therefore on normal desktop systems, having the default user be an Admin with
> sudo privileges and with lax policykit permissions makes perfect sense.
I wouldn't say that there is never a need for protecting root. By
gaining root it is much easier for an attacker to hide his existence,
for example by installing a rootkit. Furthermore, an attacker would
have direct hardware access, which could increase the harm sometimes.
Therefore it depends on the security requirements of the user.
@Seth: I see the benefits of improved sudo authentication mechanisms
in combination with AppArmor profiles. But as you wrote, such
configurations are only mitigations because of all the programs which
are not confined by an AppArmor profile. This way a user have to take
care of the programs he executes, if he wants to protect root.
Compared to my Daily-Susy approach, this strategy of watchfulness
could seem even more complex sometimes. Again it's a question of the
security requirements. Thus, I can't see any reasons for not
describing such a Daisy-Susy setup as a workaround. It would be a
suggestion rather than a proposal.
Am I right in thinking that the security problems of X11 are bypassed
if X11 is started without root privileges? If so, expanding my
Daisy-Susy approach by letting Daisy start her own X server secures
such a setup, doesn't it?
> I think this is described pretty well on the wiki page already. Which part do
> you feel needs clarifying?
I am starting with a small list of parts I found which seem misleading to me:
* https://wiki.ubuntu.com/BasicSecurity#Don.27t_Log_in_as_Root
The explanation of this rule is implying that browsing as a sudo-user
will prevent an intruder from gaining root privileges, which is wrong
as already mentioned.
* https://wiki.ubuntu.com/BasicSecurity#Least_Privileges.2C_Always
I don't know the definition of 'non-privileged user' here. If sudo
members are non-privileged users, this explanation is misleading too.
If they are defined as privileged users, I read this part as a hidden
hint for a Daisy-Susy setup ;).
* https://help.ubuntu.com/community/RootSudo#Remove_Password_Prompt_For_sudo
I guess, many people who read the text in the yellow box assume that
the password prompt is an effective protection against malicious
privilege escalations. I would say it's at most a small protection if
indeed. At least a small mention of the existence of other attack
vectors would be useful.
* https://help.ubuntu.com/community/RootSudo#Misconceptions
> The basic security model is the same, and therefore these two systems share
> their primary weaknesses. Any user who uses su or sudo must be considered to
> be a privileged user. If that user's account is compromised by an attacker,
> the attacker can also gain root privileges the next time the user does so.
> The user account is the weak link in this chain, and so must be protected
> with the same care as root.
Since the wiki page "RootSudo" is linked by the security policy page
[1], it should describe the user account concept of Ubuntu and not
only sudo in itself. Thus, _all_ the security-related pros and cons of
the Ubuntu permission concept should be described/linked here in my
opinion. Moreover some clarifications and restructurings could be
useful. I see the following to-do list:
* List and describe the other attack vectors: X11, sudo extra permissions [2];
* Marc's argument of single user setups
* Indicate whether the exploitability of some vulnerabilities is
increased if the vulnerable software has root privileges -- see also
my buffer overflow example etc.
* All this security analysis should be moved. What about putting it in
"Advantages and Disadvantages" [3]? I'm afraid that many readers don't
take note of the chapter "Misconceptions".
* Extend the list of optional security improvements on the security
FAQ [4] by Seth's sudo authentication enhancements and my Daisy-Susy
approach, and link it on the RootSudo page.
1. https://wiki.ubuntu.com/SecurityTeam/Policies#Sudo_by_Default
2. A hyper link could be useful: https://wiki.ubuntu.com/Security/Privileges
3. https://help.ubuntu.com/community/RootSudo#Advantages_and_Disadvantages
4. https://wiki.ubuntu.com/SecurityTeam/FAQ#Sudo
----- End forwarded message -----
----- Forwarded message from Edgard Schmidt -----
Date: Sun, 15 Jan 2017 06:48:25 +0100
From: Edgard Schmidt
Subject: Re: Security of sudo-setups
To: Seth Arnold
Cc: Marc Deslauriers
Hi,
we had a little discussion Ubuntu security mailing list a few months
ago. Unfortunately, I did not received any answer to my last mail. May
I ask for the reason for that?
I do not want to be pushy but I just want to ensure that you did not
forget to answer. If you have reasons for not continuing the
discussion, I will completely accept this. However, in such a case, I
would try to continue with the discussion on the ubuntu-doc mailing
list, where I began to ask my questions. So if you do not want to
write to me about this topic anymore, may I copy your previous answers
to the ubuntu-doc mailing list please? This would make the further
discussions much easier for me. :)
As a reminder, I pasted all previous mails below in chronological order.
If you answer to this, please note that I sent this mail directly to
you instead of the mailing list.
Many thanks,
Edgard
----- End forwarded message -----
----- Forwarded message from Seth Arnold -----
Date: Fri, 20 Jan 2017 14:57:21 -0800
From: Seth Arnold
Subject: Re: Security of sudo-setups
To: Edgard Schmidt
Cc: Marc Deslauriers
Hello Edgard,
On Sun, Jan 15, 2017 at 06:48:25AM +0100, Edgard Schmidt wrote:
> we had a little discussion Ubuntu security mailing list a few months ago.
> Unfortunately, I did not received any answer to my last mail. May I ask for
> the reason for that?
Between our responses it felt like most of what needed to be covered was
covered and we focussed our efforts on more pressing matters.
> I do not want to be pushy but I just want to ensure that you did not forget
> to answer. If you have reasons for not continuing the discussion, I will
> completely accept this. However, in such a case, I would try to continue
Simply a lack of time. There's so much to do and so little time to do it.
> with the discussion on the ubuntu-doc mailing list, where I began to ask my
> questions. So if you do not want to write to me about this topic anymore,
> may I copy your previous answers to the ubuntu-doc mailing list please? This
> would make the further discussions much easier for me. :)
Please feel free to forward our messages.
Thanks
----- End forwarded message -----
More information about the ubuntu-doc
mailing list