13.1 (Conspect) Permissions (part II), multi file C project

DAC (discrete access control): subject-subject model:

Discretionary access rights control. Objects with ID Users Hosts. That's why we share the access rights - minimum my files are my files. And determine what people who aren't me can do with my files.

• !Fact: You can have as many users in one group as you want. In this primitive model, a multiple subject of the group is added, resulting in 3 access rights determination points. If the process belongs to a user - and the file belongs to your user - then we refer to the access rights for the user. If the process belongs to someone who is a member of several groups and the file belongs to them - then he uses group access.

We can deny ourselves any access to the file and set three minus for ourselves but allow access to the group . If we create a file and tell it:

chmod user-rw o 

Which means that Access is forbidden.

Nobody stops you from doing the chmod again and everything will be fine. Since these attributes are bits - it's quite popular to represent these attributes in a video 8 screaming number . Because rwx - fits in 8 bits. We have one byte in 16 - two digits and in 18 river this will be slightly less than 3 - relative to t-bit. If one process is defeated by another - everything is inherited, there would be no situation in the system where there are several users. This is what user owns the most 1 process in the system, i.e. the system call setuid (setuid and setgid are access rights flags in Unix that allow users to run executable files with the rights of an owner or group of executable files.) which flouts processes to change their user ID. And run with the rights of another user - and consequently, the access rights become others that they manage to implement. Setuid is another thing - the point is that in one case we can get it all back, and in another we can't. And of course no one can take it - it's not available.

In traditional network systems, the super user is to use uid, which is 0, which is root. This root is equal to a super user who is mistakenly called an administrator account. This super user: Any process of this user has the right to violate all access rights - to write, to read and to use the directory. Access rights r and x to the directory (x versus r):

• r - Reading - access to file list
• x - use a directory to access the content of a file by its name

That is, the first problem - why after the login after sec we are given the rights of a certain user - we decided that most likely the server to which we are given access via ssh gives us access rights. This means that it goes to read your credentials compared to the hash password that you offer to start the server and from under it to start the session with your rights. There are two equal sets of parameters - in fact, they are separate keys without minus . The keys start with a minus '-'. and the parameters are not!!! In another set it will be -forest . There is a main server - one for all. All related to the session of the server - it runs under itself . After the account is checked and after rechecked. After that, with your rights runs shell - and then it is clear this key draws a tree.

That is, the buffer run technology takes a non-secure function that is started by buffers and we insert our data there and then interpret it. In short, setuid processes are dangerous - to see if there is an execution pass which is considered to be some kind of program not good . They have to do as little action as possible. What is the problem with shell, suppose I found a vulnerability in the passwd program - so the passwd program allows the user to change his password, i.e. this program must be setuid with hard attributes - nobody has to write there except root . If suddenly we find a vulnerability in any system that is run by the whole program root, then we get the keys with passwords to take the cracker through the dictionary and crack. That's why the tricky guys invented tcb - it's a lot of security complications in the system, in particular it uses one mechanism concerning shafpw There's documentation on it from the 'man'.

If the user ran passwd from these objects o can only look into his folder. In normal case, we can not get into this directory . Because tcb has rights that we can not break Passwd. All files there belong to root - nobody but root or passwd can open them and there is a password in shadow. As a result, we get a pretty funny situation where a hard hacker hacked 'passwd' and can't get a password key.

passwd

- utility of Unix-systems for managing account passwords. Use: passwd [optional parameters] After entering the command, you will be prompted to enter the existing password of the current account and asked for a new password.

!!!!!!!!!!! This technology is called 'setuid' circumvention - it will be in the exam. !!!!!!!!!!!!!!!!

Europe gallop - discretionary access control. What we like is the drive that access is 9 bits - 1 assembler room. Disadvantages: we have a file group of only 1, we can not create a latent file where one group is pasha, the other reads and 3 does not wash anything - and this is inevitable because the attributes are exactly 9 and not much. The downside is, let's say. We have a PC and some Vasya who had to run there to crack (break) passwords. But Vasya often launches it and behaves badly - a great idea is that everyone can launch it, and Vasya could not.

How do we do that? Include all 1 group and give access to use for this group and not to give someone - there are many such files - they happen. And when, for example, such a user starts, we will include them into this group too. There are 3 more disadvantages - and with the notion of root. The system has quite a lot in common that is allowed by root. Split one root into pieces and turned it. They are divided into file networks with system audit - different All these abilities are root(superuser) from the very beginning and if we give this capability only in 1 variant - there are not, that is, there are many of them. We can call the setcap utility, for example. This ping root can run - a normal user can't. Because he needs some rights related to working with the network. Let's not give this a setuid root file.