[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reporting missing package during install



On Fri, Dec 13, 2013 at 4:50 PM, Gian Uberto Lauri <saint@eng.it> wrote:
> Tom H writes:


>> In the corporate environments where I work, we are about 70 sysadmins
>> in my location and about half as much in another. We all sudo to root
>> on our more or less 11,000 systems. So by your reckoning we have 100
>> critical accounts but that's not how our internal and external
>> security auditors see it.
>
> If I understand it clearly, these sysadmins are trained users who
> (hopefully) understand what you should or should not do. I think that
> "we all sudo" means "we the sysadmin".

There's no sudo training! We prepend root commands with sudo, that's it.


> If the situation is "one machine, one sudoer, no root" is like having
> "one machine, one user, su, root can not log from the net". Slightly
> less secure, but it should be really hard to insert some hijacker that
> exploits credentials cache since the persons are properly trained.

As I've said in another email in this thread, the idea that someone or
something can monitor someone's use of sudo to root and then use the
cached credentials to run a command silently, you have far greater
problems than worrying about imaginary security holes in sudo.


>> Most of the people who have no idea that they have a critical are like
>> my parents, who have Unity installed on their laptops. When they're
>> prompted to update their systems, they do so and type in their
>> passwords when asked to, just like a Windows or OS X user. Not
>> everyone messes around with his/her configuration, uses terminals, or
>> whatever.
>
> Are you sure that nobody will be able to hijack that use of sudo, even
> from the graphic versions?
>
> My opinion is that exploiting vulnerabilities like that will be
> profitable for the "dark side users" when the number of users like
> your parent will have reached a "critical number" (like in critical
> mass).

I don't use X on Debian so I don't know how DEs are set up but gksu is
no longer used by default on Ubuntu. It's pkexec that controls
elevated permissions and it doesn't cache credentials. AFAIR gksu
didn't either when it was used; perhaps it was set up in such a way
that every access to, for example, synaptic was considered the same
thing as using a different tty/pty.


>>>>> Furthermore the sudo habit of keeping valid an authentication for a
>>>>> certain amount of time seems like an open door for malicious code
>>>>> injection.
>>>>
>>>> You can use the "timestamp_timeout" option to set this to zero.
>>>
>>> This should be the default, but is not.
>>
>> I agree. But I suspect that, as someone else has pointed out, it would
>> annoy many people to have to type their password for every
>> sudo-prepended command.
>
> If you can use any program with sudo, just sudo bash for prolonged
> administrative tasks. And close the shell when finished.
>
> Nevertheless, there is a place where sudo cache is handy. If you write
> a script for some common users, it's better to use sudo for the
> sensible command only rather than for the whole script.
>
> In these case the optimum would be to tell sudo "starting for now
> cache the credentials for a very short time - some seconds - and stop
> caching when time expires" the first time you "engage" sudo and then
> kill the caching before leaving the script, some sort of begin
> transaction/commit.
>
> Currently you can have only the very short cache time always.

The default upstream cache timeout is 5 minutes; AFAIK the Debian
default is 15 minutes. Either the credentials should be cached or not.
Caching them for a short time doesn't make sense.

If the scenario that you're considering is that you run a command with
sudo, leave a terminal open, and someone else types in a command
prepended with sudo, that's your problem; users have to take SOME
responsibility. In corporate environments, you're sanctioned if you
don't lock your screen when you're not at your desk.

At home, people can run "sudo bash" (or more appropriately, "sudo -s"
or "sudo -i") but we can't do that at my current job or other at my
previous jobs.


Reply to: