Selinux android что это
Что такое SELinux?
SELinux (Security Enhanced Linux) это система безопасности основанная на моделях мандатного и ролевого доступа. Была разработана в начале нулевых (2000-х) годов для того, чтобы исправить недостатки традиционной системы безопасности UNIX (DAC). SELinux реализована как компонент ядра Linux начиная с версии ядра 2.6. То есть SELinux можно использовать в любом дистрибутиве Linux с ядром 2.6 или более поздним. Конечно не во всех дистрибутивах использование SELinux облегчено до максимума, но в принципе можно установить почти в любом.
SELinux и DAC
SELinux работает «после» DAC. То есть операции, запрещенные в DAC не могут быть разрешены в SELinux.
Иными словами SELinux дополняет и конкретизирует действия разрешенные через DAC. При этом SELinux работает независимо от DAC.
Субъекты и объекты
Когда говорят о SELinux всегда упоминаются субъекты и объекты. То есть SELinux это разрешения и запреты которые применяются в действиях между субъектами и объектами.
Объекты это то, над чем действия выполняются. Чаще всего под объектами подразумеваются файлы данных. Но это могут быть и устройства и даже программы. Пример:
cat /var/log/syslog | grep SELinux
в этой команде программа grep объект для программы cat. И соответственно программа cat субъект по отношению к программе grep.
Как включить или выключить SELinux
Включение или выключение SELinux выполняется командой selinuxenabled с параметром 1 (включить SELinux) или 0 (выключить SELinux). Если нужно чтобы SELinux был включен/выключен при запуске системы, тогда редактировать файл /etc/selinux/config (параметр SELinux=disable).
Режимы работы SELinux
Команда sestatus позволяется узнать текущий режим работы SELinux.
Журналирование SELinux (аудит)
Контекст безопасности (метка, label) SELinux
Это набор данных состоящий из:
Если файловая система не поддерживает запись меток SELinux (как например NFS), тогда метки записываются отдельно от файлов, при этом связь между файлами и метками происходит по путям файлов. Это может привести к «разрыву» между файлом и его меткой в том случае если файл будет перемещен по другому пути (например каталог с такими файлами будет перемонтирован в другую точку монтирования).
Метка файла может оказаться неверной даже в случае если файловая система поддерживает запись таких меток, но к файлу были неправильно применены операции копирования или перемещения внутри файловой системы. Например при копировании в другую папку файл может получить метку установленную для этой папки (наследование меток), вместо той метки, которая у него была раньше. Поэтому важно правильно выполнять операции копирования и перемещения файлов при использовании SELinux.
Пользователь SELinux
Это описательный тип пользователя, а не какой-то конкретный пользователь с логином и паролем. Принципиально это то же самое что и группа пользователей в «старой» системе безопасности DAC. При добавлении, в систему, каждого нового пользователя он по умолчанию (или явным образом) сопоставляется с каким-либо типом пользователя SELinux и в дальнейшем будет иметь те разрешения или запреты, которые указаны для его типа пользователя.
Перечень разрешенных действий. Возможен переход из одной роли в другую, для изменения полномочий. При этом идентичность пользователя не изменяется (в отличии от команд su/sudo). Роли не совмещаются, они заменяют одна другую.
Политика безопасности определяет допустимые переходы из одной роли в другую. То есть невозможно перейти из любой роли в любую роль. Поскольку роли всегда связаны с типами (доменами), то часто говорят не о смене ролей, а о смене домена (Domain Transition).
Типы (домены) SELinux
Политика SELinux (SELinux Policy)
Политика MLS/MCS
Однако, логика тут есть, просто она другая. Если субъект, имеющий уровень «секретно», запишет данные в файл с уровнем «несекретно» то этот файл станет (потенциально) содержать данные уровня «секретно», но при этом будет доступен субъектам уровня «несекретно». То есть станет возможна утечка информации. Поэтому в MLS запись в файлы разрешена только с нижних уровней на верхние.
Эту особенность нужно понимать при присвоении меток уровней доступа.
Эта часть контекста используется только в специальных политиках MLS/MCS. В общих политиках типа targeted или strict эта часть контекста просто установлена в максимальный уровень разрешений и таким образом не влияет на доступ.
Резюме
Максимальную защиту SELinux дает когда переключен в режим enforced и при этом используется политика strict или политика MLS/MCS.
Если SELinux переключен в режим enforced, но используется политика targeted, то защита осуществляется только применительно к «известным» программам, для которых в политике определены разрешения и запреты. «Неизвестная» программа фактически имеет административные привилегии.
Если вы живете в г. Краснодар, для вас есть простой способ установить SELinux и научиться им пользоваться. Подробнее.
Даже небольшая сумма может помочь написанию новых статей 🙂
Или поделитесь ссылкой на эту статью со своими друзьями.
Working with SELinux on Android
Written on February 25, 2021 by Aayush Gupta (theimpulson) & Nolen Johnson (npjohnson)
Glossary
What is SELinux?
SELinux is an optional feature of the Linux kernel that provides support to enforce access control security policies to enforce MAC. It is based on the LSM framework.
History of SELinux
SELinux was originally developed by the NSA to demonstrate the value of MAC and how it can be applied to Linux. It was merged in Linux 2.6 on Aug 2003. Red Hat, and McAfee Corp. are some of the significant contributors to the development of SELinux. Later on, a separate project called Security Enhancements (SE) for Android was led by the NSA to integrate SELinux into Android. This project resulted in SELinux becoming a core part of Android. It was introduced defaulting to Permissive mode in Android 4.3, optionally Enforcing in Android 4.4, and was required by Google’s CTS to be Enforcing in Android 5.0 and above.
How does SELinux work?
SELinux can operate in 2 modes which are Enforcing and Permissive. The default mode is Enforcing.
In Enforcing mode, SELinux actively enforces the given policy which specifies what is allowed (permissions in general). If an initiator wants to perform an action, SELinux will check if it is allowed to do so in the installed policy, and if allowed, it will then permit the requested action to happen. If denied, it will be logged in the kernel log buffer along with logcat on Android.
In Permissive mode, SELinux will only log actions which are explicitly not allowed in the installed policy, and the initiators of those actions.
Below is an example of an SELinux denial printed in an android logcat :
avc: denied < write >for comm=»[email protected]» name=»tp_double_tap» dev=»proc» ino=4026533160 scontext=u:r:hal_power_default:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=0
Permissive mode is used mostly by developers during the early stages of bringing up a new device. This allows developers to save time during the initial stages of development by logging all the policy, which is needed by different process, services, firmware, etc. and address them all together once the project has reached a state of stability.
SELinux policy in a Nutshell
SELinux policy is a set of rules (permissions) which states which initiators can perform which type of actions. If a particular action the process wants to perform is not permitted explicitly in the installed policy, SELinux will deny it. Therefore, on production devices, it’s of the utmost importance to have a complete set of rules in the SELinux policy to avoid breakages/bugs due to SELinux denials. With that said, SELinux must also be as strict as possible. A good rule of thumb to remember while writing SELinux policy is: ‘If it ain’t broke, don’t fix it’.
By default, Android provides an SELinux policy for the components which are specific to the AOSP platform. You can find these stored in the platform/system/sepolicy repository of AOSP. Downstream vendors modifying AOSP and adding additional functionality must write their own SELinux policies. For example, Qualcomm provides sepolicy for devices using it’s SoCs in the device/qcom/sepolicy repository of CAF (Code Aurora Forum). LineageOS provides sepolicy to the developers for its additions/features on AOSP in the device/lineage/sepolicy repository hosted in the LineageOS GitHub organization.
All of these different SELinux policy rules are compiled together to generate device-partitions specific SELinux policy. For example, SELinux policy rules which are specific to the system partition will end up in system image, vendor partition specific rules will end up in vendor image, etc. These device-partition-specific policies are compiled together into one single SELinux policy when an Android system boots up, and this is the final policy which SELinux audits processes against.
How to write SELinux policy?
As previously mentioned, SELinux policy is just a set of rules. Writing SELinux policy encompasses everything from labeling relevant services/apps to writing rules that allow the aforementioned services to initiate actions or access other nodes/files, etc. Additionally, one can force a process to be run in Permissive mode even when the device is in Enforcing mode, though this practice should be avoided. As you can see, writing SELinux policy can easily be chunked up into a lot of smaller parts, and therefore made more manageable.
There are a lot of rules and label types that are used while writing SELinux policy. However, given the scope of the article, we will only discuss those which are recurring and basic. These statements are used by device maintainers a lot while writing device-specific SELinux policy rules.
The first step is to label the initiator, if not already done. This ensures that the permissions granted are not towards a general target but a more restricted, specific one. This results in specific initiators having only those permissions which they require to perform a specific action. These labels live in a single file named file_contexts.
Labeling an initiator (Not an App)
The blueprint is: /path/to/initiator u:object_r:context_name_you_want:s0
An example rule to label NFC service would be something like: /(vendor|system/vendor)/bin/hw/android\.hardware\[email protected]\.2-service\.sec u:object_r:hal_nfc_default_exec:s0
You should use regex to label an initiator. For example, please see platform/system/sepolicy/private/file_contexts.
Labeling an initiator (Android App)
The blueprint is: user=user_of_app seinfo=info name=name_of_app domain=scontext_to_assign type=type_of_file
An example rule to label qtidataservices app would be something like: user=radio seinfo=platform name=.qtidataservices domain=qtidataservices_app type=radio_data_file
All labels for applications go into a single file named seapp_contexts formatted as the partition requires. For example, please check platform/system/sepolicy/private/seapp_contexts.
Labeling filesystems
genfscon is a label type used to allocate contexts to file systems that don’t support any other type of labeling statements. The blueprint is: genfscon filesystem_name partial_path filesystem_context
An example rule to label /proc/hwmodel would be something like: genfscon proc /hwmodel u:object_r:proc_fih:s0
All genfscon statements go into a single file named genfs_contexts. For example, please check platform/system/sepolicy/private/genfs_contexts.
Labeling properties
The blueprint is: property_name u:object_r:property_type:s0
An example log for denial related to a camera property:
avc: denied < set >for property=camera.tunning.live pid=756 uid=1047 gid=1005 scontext=u:r:hal_camera_default:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service permissive=0
This should be addressed by labeling this specific property as camera_prop as it’s related to camera, e.g. camera.tunning.live u:object_r:camera_prop:s0
All property labels go into a single file named property_contexts. For example, please check platform/system/sepolicy/master/private/property_contexts.
Notice how labels for services, process, applications, file systems don’t end with ; unlike other statements used to grant or suppress permissions.
Once the initiator has a label, permissions can be granted to it as required to perform the desired action.
Allowing permission
If you want to allow an initiator permission for some action, you can use the allow statement. This is used to grant permission. The blueprint is: allow scontext tcontext:tclass permission;
An example in regard to this specific case:
avc: denied < read write >for pid=4565 comm=»init.qcom.post_» name=»read_ahead_kb» dev=»sysfs» ino=52742 scontext=u:r:qti_init_shell:s0 tcontext=u:object_r:sysfs_dm:s0 tclass=file
The given permission would be: allow qti_init_shell sysfs_dm:file < read write >;
Suppressing a denial
If your logs contain some denials that you want to hide/suppress for some reason, you can use the dontaudit statement. The blueprint is: dontaudit scontext tcontext:tclass permission;
An example in regard to this specific case:
avc: denied < read >for comm=»thermal-engine» name=»kgsl» dev=»sysfs» ino=29020 scontext=u:r:thermal-engine:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=0
The rule to suppress this log would be: dontaudit thermal-engine sysfs:dir read;
AOSP recommends keeping all rules (permissions, denials, log suppressions, Permissive mode) regarding a specific initiator under a separate file in the .te format having it’s scontext as the name. For example, all rules regarding an initiator having a scontext of hal_power_default would be stored in a file named hal_power_default.te. For example, please check platform/system/sepolicy/public/vold.te.
The concept of neverallow
A neverallow is an overarching rule that is used to mark specific rules that must not be generated. The word generated implies that it is a compile-time action and not runtime. Hence, if you mark a specific rule as neverallow and grant permission regarding the same in another rule, the compiler will trigger an error and the compilation will fail.
An example rule: neverallow my_gallery my_secret_passwords: < dir file >< read write open >;
In Android, you can find neverallows inside the system/sepolicy repository linked earlier in this post. Android marks several rules as neverallow which can potentially weaken the system security. For example, every file on the system has a type called system_data_file, now assume that you have an initiator which wants to access a specific file having system_data_file as type. Now, if you grant it such permission, that means you allow the initiator to read & write every file on the system (as every file in the system has the same file type). This significantly weakens security. Hence, it should be marked as a neverallow. A solution to this issue would be to label the file with a different, more specific context and then grant the initiator the required permissions. It is worth noting that if you’re on a legacy device, e.g. any QCOM chipset before msm8996 (UM-Family), that Lineage’s fork of device/qcom/sepolicy-legacy ignores neverallows, as legacy device’s proprietary binaries can’t comply with Android’s neverallows growing stricter.
While by default, a lot of rules are already marked as neverallows, not all possible exceptions are covered. It depends upon the developer to carefully grant permissions keeping all possible scenarios in mind. For reference, please check platform/system/sepolicy/public/vold.te.
Macros
By default, there are several macros available to use while writing the SELinux policy. These macros not only make writing SELinux policy easier but are also recommended to use for various reasons, such as granting a lot of permissions to a certain initiator, granting a specific set of permission for a specific task to an initiator, etc. They reduce the amount of code a developer has to write, group a specific set of rules for specific use cases, and make it easier for fellow developers to read, among many more benefits.
An example of using macros while writing SELinux policy to allow permissions would be:
Example 1: Macros used: r_file_perms
Without macros: allow hal_power_default sysfs:file < read open watch lock >;
With macros: allow hal_power_default sysfs:file r_file_perms;
Example 2: Macros used: r_dir_file
Without macros: allow ueventd firmware_file:dir < open search >; and allow ueventd firmware_file:file < read getattr open >;
With macros: r_dir_file(ueventd, firmware_file)
Notice how using macros shortens the amount of code and still granted the necessary permissions. You can check the available macros in global_macros and te_macros present in platform/system/sepolicy repository of AOSP.
Where should my sepolicy go?
Since the advent of Project Treble, sepolicy has moved from one file in the boot image, to various files on the partition relevant to those policies. For example, in device/lineage/sepolicy, under the “common” folder, we have system, vendor, public, private, and dynamic folders.
Stock SELinux policy as a reference
Some useful tools
There are some useful tools available that help working with SELinux and writing SELinux policy. Some of them are:
* chcon : Helps in changing the SELinux context of a target.
* audit2allow : Generates SELinux policy containing allow & dontaudit rules. Doesn’t cover neverallow exceptions.
* audit2allow.perl hosted at OpenDarwin-CVS/SEDarwin is a script which requires no external dependencies & runs on any platform unlike modern versions.
* restorecon : Restores the default SELinux contexts of the given target.
* sepolicy-inject : Injects allow rules into binary SELinux kernel policies.
Useful references
Here are links to some of the resources used for SELinux research during the development of this article. Feel free to check them out for more information related to SELinux in general.
Selinux android что это
Для функционирования программы необходимы права root пользователя.
Краткое описание:
Это простое приложение позволяет изменять режим SELinux, а так же запоминает ваш выбор при каждой перезагрузке устройства.
Требуется Android: 4.2+
Русский интерфейс: Нет
Обязательно следуйте инструкциям перед установкой The SELinux Switch:
Когда включен MagiskHide и вы переключаете SELinux в режим «Только предупреждение», после перезагрузки MagiskHide автоматически переведет SELinux в режим «Блокировка», однако фактически это не так. Это называется SELinux «Pseudo» State и имейте в виду, что это особенность, а не ошибка.
Вы должны убедиться, что BusyBox включен в настройках приложения Magisk, потому как по умолчанию он отключен. После включения BusyBox в Magisk, приложение The SELinux Switch будет способно изменить состояние SELinux в режим «Только предупреждение» (PERMISSIVE).
*********************
**DATE: 01-25-2018**
*********************
— The «Reviews» portion of this thread was disabled due to it being broken while navigating AND i feel that Feedback/Reviews should be posted as a thread post anyways.
— PLEASE NOTE: The «Star Ratings» were not affected.
*********************
**DATE: 12-18-2017**
*********************
— The SELinux Switch Version 6.0.7 Build 607
— App Installer & Flashable Zip Uploaded.
— Minor Correction For Cleanup Commands Within The Flashable Installer.
— Added NEW Holiday Globe Icon To App & Thread’s OP.
*********************
**DATE: 12-15-2017**
*********************
— The SELinux Switch Version 6.0.7 Build 607
— App Installer & Flashable Zip Uploaded.
— Re-Added Minor Enhancement For Quicker Launch Upon Booting Device.
— An issue was found with the Signature File and the new Version may require the member to uninstall and reinstall the app.
— As a personal suggestion, before uninstalling any app, first go to the apps details, force stop, clean/clear up the Data & Cache and then uninstall it. This helps me to make sure that I’ve done the residual cleaning before the removing of the app itself.
— I apologize for any inconveniences that this may be causing and have taken precautions to help elevate this from happening in the future.
*********************
**DATE: 12-14-2017**
*********************
— The SELinux Switch Version 6.0.6 Build 606
— App Installer & Flashable Zip Uploaded..
— Applied Some Fixes For Android Version Compatibility.
— Fixed Notification Icon For Colored Icon.
— Removed the External Installation Preference to Internal Preference.
— Improved The Background Performance For Even Lower Memory Required.
— A Few Various Other Minor Modifications Were Made.
*********************
**DATE: 10-09-2017**
*********************
— The OP of the thread was just updated for everyone to enjoy a recent article recognizing The SELinux Switch. A special thanks to @DJBhardwaj for such a great article.
*********************
**DATE: 08-29-2017**
*********************
— The SELinux Switch Version 6.0.3 Build 603
— App Installer & Flashable Zip Updated..
— Applied Some Additional Fixes To A Few Translations.
— Fixed A Forgotten Translation Translation That Was Incomplete.
— Applied A Small Functional Modification.
*********************
**DATE: 08-23-2017**
*********************
— The SELinux Switch Version 6.0.2 Build 602
— App Installer & Flashable Zip Updated..
— Applied Some Fixes.
— Applied a Few Modifications for Compatibility.
— A Special Thanks to @Thebear j koss For a Nice Dark Theme.
*********************
**DATE: 08-17-2017**
*********************
— Uploaded App Specific Screenshots On The Thread.
— Uploaded App Specific Screenshots On The XDA Labs Store.
*********************
**DATE: 08-16-2017**
*********************
— Updated Important OP Information.
— Added Important Magisk Information
— Added Important PSA Warning Information.
— Other Minor Changes/Updates Made.
*********************
**DATE: 08-08-2017**
*********************
— Launched New Thread
— App Installer & Flashable Zip Updated..
— Now available in the XDA Labs Store.
Версия 6.0.3:
The.SELinux.Switch.ver.6.0.3.build.603.apk ( 721.9 КБ )
Версия 6.0.3 для рекавери:The.SELinux.Switch.ver.6.0.3.build.603.zip ( 653.75 КБ )
Что такое SELinux? Настройка, включение и отключение
SELinux, или Security Enhanced Linux, — это продвинутый механизм управления доступом, разработанный Агентством национальной безопасности (АНБ) США для предотвращения злонамеренных вторжений. Он реализует мандатную модель управления доступом (MAC — Mandatory Access control) в дополнение к уже существующей в Linux дискреционной модели (DAC — Discretionary Access Control), то есть разрешениям на чтение, запись, выполнение.
У SELinux есть три режима работы:
1. Enforcing — ограничение доступа в соответствии с политикой. Запрещено все, что не разрешено в явном виде. Режим по умолчанию.
2. Permissive — ведёт лог действий, нарушающих политику, которые в режиме enforcing были бы запрещены, но не запрещает сами действия.
3. Disabled — полное отключение SELinux.
Изменение режима SELinux
Файл конфигурации по умолчанию, где можно изменять режим работы — /etc/selinux/config.
Чтобы узнать текущий режим работы, нужно выполнить следующую команду (для работы с SELinux необходимы root-привилегии, поэтому здесь и далее приводятся команды для root-пользователя):
Изменение режима работы на permissive:
и наоборот, на enforcing:
Полностью отключить SELinux можно только через файл конфигурации. Откройте его любым текстовым редактором
и измените параметр SELINUX на disabled:
После чего перезагрузите систему
Политики SELinux
В основе структуры безопасности SELinux лежат политики. Политика — это набор правил, определяющих ограничения и права доступа для всего, что есть в системе. Под “всем” в данном случае понимаются пользователи, роли, процессы и файлы. Политика определяет связь этих категорий друг с другом.
Для понимания политик необходимо понимание базовых терминов. Политика SELinux определяет доступ пользователей к ролям, доступ ролей к доменам и доступ доменов к типам. Разберём значение этих терминов.
Пользователи
В SELinux есть набор предварительно заданных пользователей. Каждая стандартная учётная запись пользователя Linux соответствует одному или нескольким пользователям SELinux.
В Linux пользователи запускают процессы. Это может быть пользователь ivan, открывший документ в редакторе vi (учётная запись ivan запускает процесс vi) или служебная учётная запись, запустившая демон httpd. В SELinux процесс (демон или запущенная программа) называется субъектом.
Роли
Роль определяет, какие пользователи могут осуществлять доступ к заданному процессу. Роли не тождественны группам, они больше похожи на фильтры: пользователь может принадлежать к роли в любое время, если роль это позволяет. Определение роли в политике безопасности SELinux задаёт пользователей, имеющих доступ к этой роли. Роли используются потому, что один из элементов SELinux реализует ролевую модель управления доступом (RBAC — Role Based Access Control).
Субъекты и объекты
Субъект — это процесс, который может потенциально влиять на объект.
Объектом в SELinux называется все, над чем можно выполнять какие-либо действия. Это может быть файл, директория, порт, tcp-сокет, курсор, X-сервер. Действия, которые субъект может выполнить над объектом, являются разрешениями субъекта.
Домены
Домен — это контекст, в котором может работать субъект SELinux (процесс). Этот контекст представляет собой как бы оболочку вокруг субъекта, которая сообщает процессу, что он может и не может делать. Например, домен определяет, какие файлы, директории, ссылки, устройства или порты доступны для субъекта.
Типы
Тип — это контекст для файла, который устанавливает предназначение файла. Например, контекст файла может указывать, что это веб-страница, или что файл находится в директории /etc, или что владелец этого файла — конкретный пользователь. В терминах SELinux контекст файла называется его типом.
Политика SELinux определяет доступ пользователей к ролям, доступ ролей к доменам и доступ доменов к типам. Сначала пользователь должен быть авторизован для получения роли, затем роль должна быть авторизована для доступа к доменам. Домен, в свою очередь, может осуществлять доступ только к определенным типам файлов.
Механизм, при котором процесс, запущенный в определенном домене, может осуществлять только определенные действия над определенными типами объектов, называется принудительным присвоением типов (Type Enforcement — TE).
Работа политики SELinux
Политика SELinux не заменяет традиционную дискреционную модель управления доступом (DAC). Если правило DAC запрещает пользователю доступ к файлу, правила политики SELinux не будут применяться, потому что первая линия обороны уже заблокировала доступ. SELinux начинает работать уже после DAC.
Результат будет выглядеть примерно следующим образом:
Можно заметить, что файлы связаны с различными приложениями:
Следующая команда показывает активную политику:
Изменение переключателей SELinux
Несмотря на то, что прочитать файлы модулей политики невозможно, есть простой способ их настройки. Она осуществляется при помощи булевых переключателей SELinux (boolean).
Чтобы разобраться, как они работают, запустим команду semanage с опцией boolean:
Если у вас будет ошибка
То нужно установить policycoreutils-python
Теперь запускаем semanage с опцией boolean
Будет выведен список различных переключателей, которые можно включить или выключить, краткое описание их функций и текущее состояние:
Первый пункт в этом списке позволяет демону FTP осуществлять доступ к домашним директориям пользователей. В данный момент переключатель выключен (off), то есть доступ запрещен.
Для изменения значений используется команда setsebool. В качестве примера давайте разрешим анонимный доступ FTP на запись. Проверим состояние переключателя командой getsebool:
Она покажет, что в данный момент переключатель выключен:
Изменим значение переключателя и включим его:
Снова проверим состояние переключателя, оно должно поменяться:
Теперь после перезагрузки изменения не потеряются
Заключение
Мы рассмотрели базовые принципы работы SELinux, включение системы и режимы её работы, показали пример обеспечения безопасности системы. Также была разобрана работа политики безопасности и ее настройка при помощи булевых переключателей. Более подробную информацию о SELinux можно найти в соответствующих man-страницах.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.