Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
For quiet a long time POSIX systems have got along with so called discretionary access control (DAC). It means that system trusts its applications they work as intended. If e.g. ls has the privilege to read the content of some directory, it is OK to let it read. But if someone attacker changed ls binary in a way the new application will read sensitive data and send it silently to attacker's server. The answer is to confine the application by fence of minimal access privileges they need to serve their purpose. Obviously ls has no reason to open socket connections on network layer (in any way). This principal is called mandatory access control (MAC).
SELinux is just one among many implementations of LSM (Linux Security Model) kernel framework, that brings complex MAC to Linux. The other members of LSM family are Tomoyo, AppArmor, Yama or Smack. Moreover SELinux implements FLASK (Flux Advanced Security Kernel) architecture which is more general concept describing model for flexible and dynamic type of enforcement mechanisms. FLASK architecture has its roots in 1980s and one of research projects that gave life to FLASK was designed for microkernel based operating systems. The microkernel design is well reflected even in SELinux architecture itself.
SELinux components spans over kernel space as well as user space. The kernel part consists of three strictly separated components where each one of them is responsible for its own part of a work and should be easily replaceable. This is sort of leftover from microkernel FLASK design. The core component is SELinux security server. This part is responsible for policy decisions. The second component, the AVC (access vector cache) is, and being obvious, cache that quickly responds previously returned policy decisions by security server during cache miss. The final part is a bundle of kernel object managers, that ensures type enforcement itself. Kernel object managers guarantee that any access request to its resources are properly translated into access vector queries to security server. So usual workflow looks like: You want to access inode? It's a kernel object, so kernel object manager has to query AVC for an answer. If AVC miss then it'll ask security server for an access vector decision. This decision is then stored into AVC.
For the purpose this artcle, it's enough to state that user space part of SELinux is libselinux library. What is more important: user space part of SELinux (among other things) provides interface that helps to create user space object managers. These managers are used to maintain user space objects. OK, but what are the user space objects at all? Kernel space objects are clear: inodes, files, devices, sockets etc. But why should one bother to maintain some user space objects? Consider database management system. You want to limit users to use only certain resources of dbms. You can define various objects e.g.: tables, views, triggers, db links, etc. Then, you are able to label these objects accordingly to confine db users into more clearly defined area. Libselinux has its own AVC that caches decisions for user space managed objects. But the policy decisions and SELinux types/domains are still managed by security server!
Let's look at simple example of how the type enforcement works in kernel. What will happen when process requests opening some file (access inode)? Quick search through Linux sources reveals that apart from security functions there's only one place where an inode permissions are checked. It's the fs/namei.c source file.
int __inode_permission(struct inode *inode, int mask)
{
int retval;
if (unlikely(mask & MAY_WRITE)) {
/*
* Nobody gets write access to an immutable file.
*/
if (IS_IMMUTABLE(inode))
return -EACCES;
}
/* DAC access control */
retval = do_inode_permission(inode, mask);
if (retval)
return retval;
/* cgroup checks for devices only */
retval = devcgroup_inode_permission(inode, mask);
if (retval)
return retval;
/* LSM security checks */
return security_inode_permission(inode, mask);
}
As you can see, the process of deciding whether the user has access permissions for inode or has not actually proceeds in three steps. First the classical DAC rights are checked, then cgroups (Control Groups) permissions. Cgroup permissions check takes effect only on inodes regarding block or character devices. The final check is the LSM check itself. In general that means you have to pass all three security checks to gain the access.
Access revocation is unending story about how to revoke access to resources after the permission settings are changed in a sane way. Process 'A' has access permission to some file 'F'. The process has opened the file and now it can write the file through open fd. But even if you change the access rights to the file's inode you won't interrupt the process 'A' from writing the file through open fd. Only each future call to open syscall will fail. What SELinux offers is actually 'sort of' revocation by changing the object's type. In our case you can change inode's type and during the next write syscall, SELinux will fail the write call. It shouldn't be expensive as after first query the AVC will store the access decision and every following write call will receive the answer from AVC. Actually, SELinux hook function can detect if security context of inode has changed since the file has been opened. LSM support this feature by security_file_permission hook and it's up to security module if it implements it or not. Did you know that?:)
If you glimpse shortly into linux/security.h header file you'll find out there are hook functions for most of the system calls. But especially one syscall, the ioctl is a bit different. Ioctl syscall represents kernel configuration interface used to interchange data between user space and kernel space. In the beginning it's been used as configuration interface for tty devices solely, but later it's become general configuration interface. Nowadays, there are dozens of different ioctl calls in the kernel. List of devices that are configured by ioctl syscall is quite a long one: all *-ROM mechanics, SCSI devices, device-mapper virtual devices, loop devices, etc. What is a real challenge with the ioctl syscall is the fact, that ioctl is actually a syscall to implement new syscall within the kernel. Why so? The ioctl syscall prototype is:
int ioctl(int fd, unsigned long commmand, ...);
commmand parameter is an ioctl identifier number. The id contains information about command type and its direction (write data to kernel, read data into user space). The third variable parameter can be of any type or null. There are two major arguments why security people don't like the ioctl syscall. The first reason is, that ioctl handler (usually a device driver) has to be very careful about the third parameter passed from user space. The user memory has to be copied into kernel memory space and you need to check if every string is correctly terminated. Fail to do and you risk that user try to do some ugly things with the memory beyond the unterminated string. The second argument is simple. If you consider the abundant quantity of different ioctl implementations you will simply realise that its nearly impossible to verify every ioctl. The security maintainer would have to check every ioctl implementation and also he would have to completely understand what is driver trying to do during the ioctl handling. For example: you can have driver that receives read only ioctl parameter. That means the driver will fill user provided area with some data from kernel. It's supposed to supply some statistic data about device usage. But the driver author may have decided to do some potentially harmful operation during ioctl handling (for example reset the statistic data to initial value). Do you want that operation to be accessed by general user? Or rather, do you want only some privileged user to do that operation. And who should decide that? In any way, this decision should not be made be SELinux maintainers but by the person responsible for the device driver. And I don't even mention that some drivers are at least partially rewritten from time to time. So if you look into SELinux implementation of security_file_ioctl hook you'll find out that there are only a few ioctl commands that SELinux cares about:
static int selinux_file_ioctl(struct file *file, unsigned int cmd,
unsigned long arg) {
/* ... */
switch (cmd) {
case FIONREAD:
/* fall through */
case FIBMAP:
/* fall through */
case FIGETBSZ:
/* fall through */
case FS_IOC_GETFLAGS:
/* fall through */
case FS_IOC_GETVERSION:
error = file_has_perm(cred, file, FILE__GETATTR);
break;
case FS_IOC_SETFLAGS:
/* fall through */
case FS_IOC_SETVERSION:
error = file_has_perm(cred, file, FILE__SETATTR);
break;
/* sys_ioctl() checks */
case FIONBIO:
/* fall through */
case FIOASYNC:
error = file_has_perm(cred, file, 0);
break;
case KDSKBENT:
case KDSKBSENT:
error = cred_has_capability(cred, CAP_SYS_TTY_CONFIG,
SECURITY_CAP_AUDIT);
break;
/* default case assumes that the command will go
* to the file's ioctl() function.
*/
default:
error = file_has_perm(cred, file, FILE__IOCTL);
}
return error;
}
As you can see only a few ioctl commands are somehow translated into more specific SELinux permission checks like FILE__GETATTR or FILE__SETATTR. The default behaviour is to check only general FILE__IOCTL permission or in other words: SELinux verifies if current process is in proper domain to do ioctl on open file. The short answer on question why SELinux doesn't care about the specific ioctl commands is that only the driver's author (should :)) knows about the driver's internals.
I hope you find at least some parts of the blog entry interesting and feel free to discuss any misleading info or clear mistakes. Thanks you for reading
Tiskni Sdílej:
Jestli máte někoho kvalitativně srovnatelného v zásobě, tak si rád přečtu.James Joyce. Četl jsem od něj jen sbírku povídek Dubliners, ale stála za to.
ls
je dobrý v tom, že je jednoduchý a jasný. Na druhou stranu je to ale utilita a spouští se obvykle z shellu nebo jiné čistě uživatelské aplikace. Tudíž běží obvykle s právy uživatele
a navíc alespoň ve Fedoře nemá nastavený žádný speciální typ.
$ ls -Z /bin/ls -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /bin/lsTakže z praktického hlediska postrádá smysl a lepší by bylo jako příklad použít něco, co se opravdu SELinuxem už dneska v praxi zabezpečuje nebo to alespoň dává nějaký konkrétní smysl. Snad to pomůže.
Jinak taky budu potřebovat omezit FTP pro jednoho kolegu, ale to zatím nespěchá (FTP pojede, až dodá disk) a předpokládám že konfigurák někde najdu.Kdybys na to chtěl přeci jen zkusit selinux, tak se obejdeš bez vlastních politik, stačí ti to jenom nastavit
podle ftpd_selinux (8)
(a na fedoře ještě předtím doinstalovat policycoreutils-python
, v kterých je semanage
).