Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Note that as of
5eaf563e53294d6696e651466697eb9d491f3946,
you can now mount filesystems as an unprivileged user after a call
to unshare(CLONE_NEWUSER | CLONE_NEWNS), or a similar clone(2)
call. This means all those random random filesystem bugs you have
laying around in the junk bin are now quite useful. ++tricks;
— Jason A. Donenfeld
I suspect part of the problem is scale. Most people don't
understand the scale at which the Linux Kernel and vendors handle
bug fixes and code changes. External people simply see a few poorly
handled security related issues and probably think "well how hard
can it be to properly a few extra security flaws?" but they don't
see that those 5 security issues were buried in 10,000 other code
fixes. The resources needed to audit every code change for a
security impact simply aren't available (and even if we had enough
talented people who exactly is going to pay them all?).
— Kurt Seifried
This naming alone would inhibit [BUG_ON()] use through two channels:
— Ingo Molnar
(Log in to post comments)
Quotes of the week Posted Feb 28, 2013 13:51 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> Note that as of 5eaf563e53294d6696e651466697eb9d491f3946, you can now mount filesystems as an unprivileged user...
I have always wondered why this is not generally allowed if a user has the right access to the underlying device and to the mount point (thought experiment: imagine that the user had the rights required to manually create a tree under the mount point identical to what is stored on the device and to update the device when someone changed the tree).
Quotes of the week Posted Feb 28, 2013 19:39 UTC (Thu) by spender (subscriber, #23067) [Link]
A number of things: the filesystem could intentionally contain suid root binaries, world-readable/writable device files, etc. Additionally, auditing and fixing vulnerabilities in the parsing of filesystems isn't a huge priority among kernel developers (which is one of the reasons why removing the privilege check for user namespaces was extremely premature). It's effectively the same impact as if a bunch of buggy, exploitable system calls were added. You would hope considerable care would be taken in the latter case. This hasn't happened with user namespaces.
-Brad
Quotes of the week Posted Feb 28, 2013 20:59 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> A number of things: the filesystem could intentionally contain suid root binaries, world-readable/writable device files, etc.
I am assuming (see the thought experiment) that the unprivileged user would not normally have the right to create these files if you leave mounting the file system out of the picture.
Quotes of the week Posted Feb 28, 2013 21:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I think the point is that you can't enforce a restriction like that when the user can mount a filesystem of their own creation with their own files and device nodes on it, unless the filesystem is mounted with the nodev,nosuid flags.
Quotes of the week Posted Mar 1, 2013 2:09 UTC (Fri) by Trelane (subscriber, #56877) [Link]
Why cant user mounts automatically have these options added?
Quotes of the week Posted Mar 1, 2013 8:50 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
> Why cant user mounts automatically have these options added?
As well as restrictions on the allowed groups and users of the files and directories in the mounted file system.
Quotes of the week Posted Mar 5, 2013 17:40 UTC (Tue) by viro (subscriber, #7872) [Link]
nosuid/nodev somewhat reduce the former. The latter, however, is a really serious problem. Especially since it's not just parsing the filesystems - if an attacker creates an image in regular file, mounts it with -o loop (i.e. sets /dev/loop over it and mounts that) and starts modifying that file right under the nose of fs code... That's one hell of unpleasant attack surface.
I'm rather sceptical about the whole thing, to be honest - I wouldn't give CAP_SYS_ADMIN in containers to anyone. Not on my damn boxen, TYVM...
Quotes of the week Posted Feb 28, 2013 13:57 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> The resources needed to audit every code change for a security impact simply aren't available (and even if we had enough talented people who exactly is going to pay them all?).
Sounds like a job for an insurance. The customer decides how much they are willing to pay for how much coverage in the event of a security incident and the insurance decides, based on the sums involved and an evaluation of the customer's risk, how much money it is worth spending on auditing and on paying kernel programmers to fix bugs. It might also give a more-or-less reasonable metric for kernel security, perhaps also relative to other systems.
Quotes of the week Posted Mar 5, 2013 16:43 UTC (Tue) by ortalo (subscriber, #4654) [Link]
<joke>Sounds like an antivirus business also somehow...</joke>
However, I do not fully agree. Insurances do not spend the money for prevention activities, they put it aside for indemnification of victims. (Their existence is for you to transfer the risk to them - not reduce it.)
Risk reduction activities is more like a government action in fact: they raise taxes on you and imposes norms and standards on everyone and do (or fund depending on the country) the prevention jobs that nobody sees worth it at an individual level and only make sense collectively (like police forces, flooding prevention, health care, etc.).
Furthermore, Departement of Hacking Security sounds really fun compared to what exists currently (personnally I am french and still wondering about a suitable translation).
Quotes of the week Posted Mar 5, 2013 16:58 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
> Furthermore, Departement of Hacking Security sounds really fun compared to what exists currently (personnally I am french and still wondering about a suitable translation).
Direction générale de la sécurité anti-hack?
Quotes of the week Posted Mar 6, 2013 9:12 UTC (Wed) by ortalo (subscriber, #4654) [Link]
Agence Tous Hacks? (Ca vous parle?)
Quotes of the week Posted Mar 5, 2013 18:26 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> However, I do not fully agree. Insurances do not spend the money for prevention activities, they put it aside for indemnification of victims. (Their existence is for you to transfer the risk to them - not reduce it.)
What that is essentially true, insurance premiums are tied to the risk which is being insured, so it makes perfect sense for insurance agencies to offer discounts to clients which engage in prevention activities.
Quotes of the week Posted Mar 6, 2013 9:14 UTC (Wed) by ortalo (subscriber, #4654) [Link]
Exact. See below (same remark from another commenter).
Quotes of the week Posted Mar 5, 2013 22:32 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> However, I do not fully agree. Insurances do not spend the money for prevention activities, they put it aside for indemnification of victims. (Their existence is for you to transfer the risk to them - not reduce it.)
Insurance does not spend the money on prevention activities, but competent insurance charges you less money if you implement prevention (reducing the probability that the insurance company will have to pay out on a claim)
Quotes of the week Posted Mar 6, 2013 9:23 UTC (Wed) by ortalo (subscriber, #4654) [Link]
True. However, how does that differentiate from governemental implication with respect to public investment in security?
Insurances try to minimize the risk, but they accepted to insure that risk in the first place. So that's just a moral question on where you spend the money (less victims or more indemnification...) but the game is cheated.
However the funding problem issue (whether based on real money or motivation or volunteer time) is pretty similar. Collective action is needed.
Quotes of the week Posted Mar 7, 2013 2:54 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
actually, governments, just like private companies, can ignore or falsely evaluate risks and what they need to do to deal with them.
And they do on a regular basis.
They either accept the loss, fix the problem, or try to make it someone else's problem in the future (pretending that it never happened is one form of accepting the loss, and both governments and private companies do this)
Quotes of the week Posted Mar 7, 2013 13:53 UTC (Thu) by heijo (guest, #88363) [Link]
> Note that as of 5eaf563e53294d6696e651466697eb9d491f3946, you can now mount filesystems as an unprivileged user...
WHAT?
They did this all of a sudden?!?
Seriously?
I'm going to bet EVERY SINGLE FILESYSTEM contains at least a local root exploit now.
Quotes of the week Posted Mar 8, 2013 4:32 UTC (Fri) by kevinm (guest, #69913) [Link]
Only if you have CONFIG_USER_NS enabled, which is not enabled by default. If you don't need user namespaces, don't enable them - they do increase the attack surface for local exploits.
Quotes of the week Posted Mar 8, 2013 23:04 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Well, I'd like to experiment with getting VPN access to a single tmux server and nothing else and to do that without mucking with root (which I have to do now anyways to manage resolv.conf since that doesn't update). I'd certainly like to not have to shove *all* of my traffic over the VPN network, just what is necessary.
CRIU is also something I'd like to try, which, if I'm not mistaken, should be able to be used without root with user namespaces.
|
|||||||||||||