Bash en Windows 10 fue solo el inicio, la Creators Update integra un entorno que luce y se comporta exactamente como Linux

Como siempre, excelente en tus comentarios.

No soy joven, probablemente tenga tu edad o poco menos. No he nombrado NT porque era un sistema que salió para ser usado en empresas, no para usuarios finales, aunque ambos sabemos que XP fue el NT para usuarios (heredando su núcleo).

El resto de cosas son como dices. Y si no fuera por Windows y su "facilidad" de cara a los usuarios, nunca se hubiera popularizado la informática como lo hizo. Para usar Linux, aún hoy, hay que saber algunas cosas que la gran mayoría desconoce. Pero es que antes había que saber un montón de cosas que ninguna persona sin interés en la informática aprendería en su sano juicio.

Facilidad -> libertad -> peligro

En fin, usuario Windows desde que salió al mercado y creo que me entró un virus en los años 90...

Ese es el problema de Windows: el uso que se le da.

Por defecto, Windows te crea una cuenta de administrador, el problema es que la gente que lo instala no entiende que ese usuario es para terminar de instalar y configurar las cosas y que el usuario final debe quedar en una cuenta no admin, así la gran mayoría de los virus no se ejecutarán por mucho que quieras.

Un usuario administrador NO puede instalar cosas ni copiar archivos más allá de su carpeta de usuario. Para hacerlo tienes que ser administrador elevado, es decir, tienes que haber pasado por el UAC para que eleve. Hay mucho desconocimiento de cómo funciona el sistema de permiso de Windows.

El UAC se puede configurar para pedir la contraseña de la cuenta o para usar tarjetas inteligentes y otros métodos de autenticación. En las ediciones Home y Pro viene configurado así porque es más cómodo para los usuarios, pero aún así puedes cambiar la configuración. En las ediciones Enterprise y Server ya es otra historia.

Si no te gusta tener que elevar con Si/No + Escritorio seguro, puedes canbiarlo en el registro de Windows (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System) o en el editor de políticas.

A mi no me lo tienes que explicar, sino al usuario de a pie. Ya expliqué lo que hace por defecto, ahora diles tú los pasos a configurar, verás las risas.

El usuario de a pie está lo suficientemente seguro con el UAC Si/No + Windows Defender + Smartscreen.

No comparto esa opinión.

https://www.genbeta.com/windows/las-cuentas-con-privilegios-de-administrador-son-responsables-de-la-inseguridad-de-windows

¿Todo el mundo es capaz de recordar la contraseña para iniciar sesión y no van a recordarla para instalar algo?

Lo que me asusta es que algunos estéis justificando este problema con que la otra solución (pedir la contraseña) es peor. Ya puestos que no pida Windows poner una contraseña a la hora de crear un usuario. Total...

Windows no obliga a poner una contraseña a una cuenta de usuario, se puede iniciar la sesión sin contraseña. Y la misión del UAC no es autenticar al usuario si no cambiar los tokens de seguridad.

Leches, he reescrito este mensaje 200.000 veces.

Y sigues creyendo tras 200.000 mil veces, que UAC es un muro anti-malware. Que te protegerá system32 y ni ningún malware se instalará sin tu conocimiento. Y no es así.

No te líes. Si estás usando la cuenta administrador por defecto (la gran mayoría) UAC no va a parar el malware, pues la inmesa mayoría se lo saltan (hay maneras conocidas de hacerlo). UAC solo es eficaz cuando trabajamos sin cuenta administrador, y en lugar de un booleano, nos pide una contraseña.

Si estás en Linux y le das permisos a una aplicación para hacer ciertas cosas,[...] El usuario te ha dado permisos para hacer lo que tu quieres hacer con sudo, pero yo se que eres maligno, ¡MUERE!

No he entendido lo que quieres decir.

Y te vuelvo a repetir que el que estás equivocado eres tú. Un usuario administrador no tiene privilegios para operar fuera de su carpeta de usuario, te pongas como te pongas.

Te empeñas en repetir una mentira de algo que se nota que desconoces completamente quién sabe con que intenciones. ¡Venga, pruébalo tu mismo! Coge Windows 10, crea una cuenta de administrador e intenta borrar cualquier archivo de system32.

Cuándo no puedas vienes con el rabo entre las piernas, primero porque el administrador no tiene privilegios para ello. Segundo, porque aunque uses el modo elevado (y por lo tanto tengas que pasar por el UAC) tampoco podrás porque el administrador elevado tampoco tiene privilegios para tocar en system32. Necesitas ser TrustedInstaller para poder escribir en system32.

Que os creéis que el sistema de seguridad de Windows lo ha diseñado un niño de 3 años, y lo ha diseñado gente muy competente. Deja ya la sarta de tonterías y equivocaciones para la gente que quiere aprender que estás diciendo, anda.

Un usuario administrador no tiene privilegios para operar fuera de su carpeta de usuario, te pongas como te pongas.

Yo no he dicho que un usuario administrador tenga permisos para modificar system32, he dicho un malware ;).

Cuándo no puedas vienes con el rabo entre las piernas,

Bueno, quizás vuelvas tú cuando un malware obtenga permisos para poder ejecutarse y asi, aprovechar una vulnerabilidad, por no tener la puta contraseña por defecto, lo cuál bloquearía su ejecución indebida. Llámame loco.

Que os creéis que el sistema de seguridad de Windows lo ha diseñado un niño de 3 años,

Eso lo has dicho tú. A mi el sistema en anillos de Windows me gusta.

Deja ya la sarta de tonterías y equivocaciones para la gente que quiere aprender que estás diciendo, anda.

O quizás seas tú el que está desinformando. Me parece mentira que apruebes la práctica por defecto de no pedir contraseña, y mas viniendo de tu parte.

Por supuesto que apruebo la práctica de no pedir contraseña. Para empezar porque el malware del que hablas no sabes tú ni cual es porque NO EXISTE.

El UAC (Si, ese que no pide contraseña por defecto) se ejecuta bajo el escritorio seguro, por lo que es IMPOSIBLE que una aplicación accione el botón sí/permitir de manera automatizada.

Así que para evaluar tu teoría la pregunta sería ¿Qué diferencia hay entre la opción Si/No y la contraseña? Diferencias de seguridad ninguna. Las dos opciones son iguales de seguras, lo que cambia es cómo da el usuario el permiso. Partes de una premisa ridícula, y es que la contraseña es más segura que el SI/NO, lo cual es mentira.

La contraseña es mas tediosa de introducir. Las protecciones que hay debajo son las mismas. La seguridad es la misma. Ambos se piden en el escritorio seguro. No hay virtualmente ninguna diferencia para el malware entre un método y otro.

Si un malware consigue hacer click o accionar de una manera el botón permitir/si del diálogo del UAC también conseguirá leer el textbox donde está almacenada la contraseña. Tu argumento se cae por su propio peso.

El UAC (Si, ese que no pide contraseña por defecto) se ejecuta bajo el escritorio seguro, por lo que es IMPOSIBLE que una aplicación accione el botón sí/permitir de manera automatizada.

Que si compañero, que si. Que la UAC es infalible e intachable. Tócate los machos. Adiós.

https://www.fuzzysecurity.com/tutorials/27.html

Vamos a ver, señor "tocate los machos". La ejecución de Scripts de Powershell en Windows está deshabilitada por defecto POR SEGURIDAD, por lo que ese script no se puede ni ejecutar sin aceptar antes unos cuantos mensajes que te alertan lo suficiente ni sin pasar antes por el UAC.

Mira el mensaje que muestra cuando cambias la política de scripts en Powershell, te lo copio tal cual: "La directiva de ejecución le ayuda a protegerse de scripts en los que no confía. Si cambia dicha directiva podrá exponerse a los riesgo de seguridad (...). Buen método. Ah, y como ya te he dicho antes, para cambiar la directiva de ejecución hay que usar el UAC, ya que solo cambia en modo elevado.

¡Enhorabuena! Has deshabilitado el UAC teniendo que aprobarlo antes con el propio UAC. Desde luego aquí se echa uno unas risas... Tócate los machos.

Si te hubieses leído el artículo no hubieses dicho tantas chorradas.

Para aprobar los scripts en powershell saltándose la UAC, se utilizan binarios de Windows (firmados por Microsoft) a nivel de usuario que poseen la opción autoelevate activa (es decir, elevan privilegios sin necesidad de UAC). Estos scripts solo funcionan mientras se utilice el usuario administrador, ya que son los únicos que tienen permisos de autoelevate.

¡Anda! ¡Si resulta que el diseño de UAC tiene errores! ¡Como el resto de sistemas operativos!

¿Sabes como todos estos exploits son impoibles de ejecutar? Cuando se utiliza un usuario sin privilegios, porque ningún binario a nivel de usuario bajo, tiene poder autoelevate. ¡Anda, tócate los machos!

Palabras textuales de Chema Alonso, uno de los mejores doctores en seguridad informática del mundo y MVP de Microsoft 4 años seguidos, palabras de hace 2 semanas:

Muchas eran las quejas de los usuarios sobre UAC (User Account Control) cuando fue introducido por Microsoft en Windows Vista, pero lo cierto es que desde que se rebajó el nivel de seguridad en Windows 7, 8, 8.1 y 10, son constantes las pruebas de concepto de nuevas formas de utilizar la opción de autoElevate para saltarse UAC, lo que hace que sea bastante inútil en su configuración por defecto.

¡Anda! ¡Si es lo que te llevo diciendo desde el principio! ¿Que cosas verdad?

Venga, sigue diciéndole a la gente que la configuración de Windows por defecto es suficiente.

Ahora ya me has cambiado las premisas. Ya no hablas de la opción binaria porque ya no te interesa (o lo que es lo mismo, me estás dando la razón).

Evidentemente es de cabeza que el UAC configurado para que no pida elevación para operaciones del sistema *que es de lo que habla Chema* es menos seguro que configurado para que si lo haga. Y esto es de cajón. Y Chema tiene razón.

Y lamentablemente para tí esto no tiene que ver nada con nuestro debate, porque Chema en ningun momento habla del si/no frente a contraseña. De hecho, tal mal está tu postura (que se ve que ya te has cansado de defenderla) que poniendo contraseña para elevar seguiríamos poniendo elevar mediante este vector de ataque, porque no tiene nada que ver. Mi premisa de que el si no es tan seguro como la contraseña queda intacta.

Gracias por desviar el tema.

Yo no te he desviado ningún tema. Puedes revisar mis comentarios y comprobarlo. En mas de una ocasión has puesto palabras en mi boca que no he dicho (como que los programadores de Microsoft son monos o que Windows es inseguro), posiblemente por leer rápido, en lugar de leer detenidamente.

Te llevo diciendo desde el principio que la UAC por defecto se salta con facilidad. Te decía que comprendía la práctica de Microsoft de encontrar un equilibrio entre seguridad y el "no molestar" al usuario. Pero también te decía que no me parece la práctica mas apropiada pues, como pudiste comprobar en el articulo que te enlacé, el 95% de las vulnerabilidades se vuelven inviables al usar una cuenta sin privilegios.

Tú decías que la configuración por defecto es más que suficiente y que nada puede saltarse la UAC (lo dijiste), acabas de ver como todo diseño tiene flancos. La UAC tiene flancos para aprovechar una escalada de privilegios y ejecutar cualquier script que necesites (incluso de manera remota) aprovechando un binario que se ejecuta en el espacio de usuario administrador (nada de super-administrador) y, que a raíz de aquí, pueden modificarse partes del sistema gracias a código que se ejecuta en un nivel de integridad alto.

porque Chema en ningun momento habla del si/no frente a contraseña.

Si lo está haciendo. Voy a volver a ponerte la parte importante del texto: "lo que hace que sea bastante inútil en su configuración por defecto."

No sabía que Windows por defecto te pida la contraseña. El hecho de trabajar con un usuario sin privilegios y bajar un anillo, obliga al sistema a pasar siempre por el protocolo de "over the shoulder" (a no ser que bloqueemos las peticiones desde la UAC).

Independientemente de todo esto, tu premisa esta completamente rota desde el momento en el que dijiste que el usuario administrador por defecto + UAC + Smartscreen es suficiente.

Me limito a citarte la solución del equipo de Chema Alonso para estos casos:

Evitar el uso de UAC, creando un usuario sin privilegios de verdad. Si se utiliza UAC, elevar su seguridad a "modo Windows Vista". Y para el resto de elevaciones... parchear y mejorar la seguridad del equipo en general (muchas se ven mitigadas si se toman las precauciones previas necesarias).

Lo del batch en la carpeta de inicio te garantizo que no permite ejecutar nada que requiera privilegios de administrador. Y si un programa en esa carpeta intenta elevar privilegios durante el arranque Windows simplemente ignorará la petición y el programa ni siquiera se ejecutará (Esto es así desde Windows Vista).

Por eso los programadores con mentalidad obsoleta cuando quieren replicar esta antigua forma de trabajar usan el programador de tareas para lanzar en el inicio algo que requiera elevación. Pero claro, para haber metido esa tarea en el programador de tareas necesitas hacerlo desde un programa que ya ha elevado privilegios, como pasaría en Linux.

Windows permite crear igual que Mac o Linux un usuario sin privilegios y un administrador con clave, y en cuanto quieras instalar algo o cualquier cosa necesite elevación te solicitara la clave. Lo malo es que mucha gente no lo sabe, o está mal acostumbrada y simplemente crea su cuenta como administrador para trabajar y punto.

Es la única pega que se le puede poner a los Windows actuales, el que no fuercen este modo de trabajar y que un usuario novato probablemente ni se plantee usarlo así.

Estás completamente equivocado. Precisamente un usuario Administrador antes de pasar por el UAC aunque pertenezca al grupo de Administradores no tiene privilegios de administrador porque dichos privilegios no se encuentra en el token por defecto de permisos de un usuario administrador sin elevación.

Precisamente, cuándo se pasa por el UAC es cuando se le añade al token los privilegios de administrador y - siendo el usuario el mismo -, cosa que es muy fácil de comprobar, tiene privilegios de administrador. Ningún usuario en Windows a excepción de SYSTEM puede elevarse de forma autónoma, y cualquier usuario, sea administrador o no lo sea, tendrá que pasar por el UAC para cada ejecutable que quiera elevar. Un administrador no puede copiar archivos a system32, un administrador elevado si. Y para ello ha tenido que pasar por el UAC, o haber iniciado dicha copia un ejecutable firmado ya anteriormente elevado por el UAC.

Sinceramente, repásate el sistema de permisos de Windows porque lo desconoces absolutamente.

Sinceramente, repásate el sistema de permisos de Windows porque lo desconoces absolutamente.

Que la teoría donde todo es perfecto está muy bien. Me conozco el sistema bien. Lo que parece que se te olvida es del maldito malware que hay por toda la web y que se autoejecuta sin permiso (de hecho no se saltan la UAC, la aceptan ellos mismos en un backgui) por no poner una maldita contraseña.

Seguir diciendo que este método es perfecto y lo mejor que hay, a mi me parece una cagada, la mires por donde la mires.

Vamos a ver, antes de decir lo que has dicho búscate en internet lo que es el Secure Desktop que usa el UAC, mírate que corre en un Shell diferente y en una sesión diferente y luego ya repasas lo que dices del Backgui, que es una bobada.

Y lo vuelvo a poner, sinceramente, repásate el sistema de permisos de Windows porque lo desconoces absolutamente.

Para ti la piedra. No pienso discutir con una persona que defiende el sistema de escala, el cual es saltable, con un simple SI o NO en lugar de contraseña, simplemente porque lo hace sus sistema favorito.

Arriba te puse un link, yo no sigo esta discusión absurda.

Hasta luego.

Lo del link de arriba ya está más que rebatido... Repásate el comentario, anda. Pretendes saltarte el UAC con un script que necesita al UAC para poder cambiar una política de seguridad para ejecutarse, porque si no ni se ejecuta :)

Sinceramente, la discusión no te lleva por ningún lado. Demuéstrame que se puede pasar la seguridad del UAC con el SI/NO. Un exe que lo haga, venta. Y aún así, si consiguieras demostrarlo (que va a ser que no) además tendrías que demostrar que con el mismo método no se puede saltar con contraseña.

La única diferencia de seguridad entre el SI/No y la contraseña es el tipo que está delante de la pantalla, que probablemente se lo pìense más al escribir una contraseña. La seguridad a nivel sistema es exactamente la misma. Te pongas como te pongas.

Si un programa te pide un permiso para hacer algo, y tu se lo concedes, LO HARÁ.

Andas mas perdido que el chiquillo de la llorona. Para llamar pesado a alguien, primero entérate de la conversación.

Los scripts y exploits que estamos hablando, se ejecutan sin pedir permiso al usuario.

Empiezo a pensar que tienes algún problema mental que te impide relacionar causa-efecto.

Empieza por mejorar tu comprensión lectora, que es tu principal problema. Maleducado.

Hace mucho que no usas Windows. En Windows para tener acceso a system32 necesitas permisos de administrador elevado, y no puedes crear un usuario que sea administrador elevado por defecto. No puedes copiar archivos a system32 salvo si pasas por el UAC antes. Que lo tengas configurado para que te pida la contraseña o para hacer un click en un si ya es cosa tuya.

Se refiere a la instalación por defecto. En windows te compras un ordenador y la cuenta que te crea es de administrador con UAC a un solo click, para que tu hijo pequeño le pueda dar sin problemas.

En Linux instalas y la cuenta por defecto es de usuario y con contraseña para tareas administrativas.

En windows puedes securizarlo lo que quieras a partir de ahí y en linux relajar la seguridad pero el 99% de los usurios no lo hacen.

Acabo de ir a System32, he creado un archivo, lo he borrado y sin problema oiga. Comprueba las cosas antes de asegurarlo de esa manera.

Además, quién no ha modificado el archivo hosts que está en un subdirectorio de System32

MMM... justo para eso esta solo disponible si activas el modo desarrollador xD.

Creo que no te has informado correctamente.

Llevo un tiempo probándolo en windows 10 y tiene algunas limitaciones bastante importantes. La principal es que no hay ningún entorno gráfico, sólo se soportan aplicaciones de consola. Otra muy importante es el acceso al hardware, que está muy limitado.

Por ejemplo, no puedes acceder al USB para abrir una comunicación serie con un una placa de desarrollo tipo arduino (si ejecutas un simple "lsusb" para ver los dispositivos conectados, da error).

Por lo demás, no funciona mal para lanzar scripts y ejecutar programas sencillos de consola. Cuando no puede usar linux (por ejemplo, en el ordenador del trabajo), es un sustituto aceptable.

Yo no lío ninguna. Linux es un sistema operativo excelente que yo mismo uso a diario.

Pero hay gente muy fanática y que habla sin conocimiento que creen que Microsoft es una compañía que ha montado un quickstarter para hacer un sistema operativo, y resulta que no, que Windows está bien hecho.

Y la prevalencia de Linux en servidores no creo que tenga que ver nada con la seguridad, igual que la prevalencia de Windows en el escritorio tampoco. Pero ese es otro debate.

Es solo una característica que ayuda a tener algo de la potencia de Linux (no es toda y no es una terminal completa) aún cuando estés en Windows, cosa que se agradece, pero no creo que alguien se cambie solo porque ahora tiene una terminal de linux capada, ya que en ese caso mucha gente de Windows se hubiera ido a Linux a causa de Wine (una capa de compatibilidad con programdas de Windows capada).

PD: Con wine no se emula (Wine Is Not an Emulator), es una capa de compatibilidad.

ha habido mucha gente que se ha pasado a Linux debido a que existía Wine.

Wine es un último recurso: Algunas cosas corren excelente y otra gran cantidad no, por lo que no sirve como argumento positivo, solo como paliativo, dudo mucho que tu afirmación sea verdadera.

Nadie se va a Linux por Wine, como mucho evita tener que reinicar para levantar Windows o tener que tirar de una máquina virtual cuando necesita usar un programa exclusivo de Windows.